<<< Date Index >>>     <<< Thread Index >>>

Fwd: [Re: cvs commit: src/sys/vm vm_map.c]



Hello,

FYI:
A FreeBSD user suggested that this issue requires a security advisory.
The issue has been public for some time, but currently, FreeBSD does not
issue advisories for local denial-of-service issues.  It is expected
that this bug will soon be fixed in FreeBSD 4.x (it is already fixed
in FreeBSD 5.x, as you can see below).

Cheers,
-- 
Jacques Vidrine <nectar@xxxxxxxxxxx>

----- Forwarded message from Tim Robbins <tjr@xxxxxxxxxxx> -----

Date: Tue, 23 Mar 2004 21:53:10 +1100
From: Tim Robbins <tjr@xxxxxxxxxxx>
To: Pawel Jakub Dawidek <pjd@xxxxxxxxxxx>
cc: cvs-src@xxxxxxxxxxx
cc: src-committers@xxxxxxxxxxx
cc: cvs-all@xxxxxxxxxxx
Subject: Re: cvs commit: src/sys/vm vm_map.c
Message-ID: <20040323105310.GA14855@xxxxxxxxxxxxxxxxxxxxxxxxxx>

On Tue, Mar 23, 2004 at 11:33:00AM +0100, Pawel Jakub Dawidek wrote:

> On Tue, Mar 23, 2004 at 12:37:35AM -0800, Tim J. Robbins wrote:
> +> tjr         2004/03/23 00:37:34 PST
> +> 
> +>   FreeBSD src repository
> +> 
> +>   Modified files:
> +>     sys/vm               vm_map.c 
> +>   Log:
> +>   Do not copy vm_exitingcnt to the new vmspace in vmspace_exec(). Copying
> +>   it led to impossibly high values in the new vmspace, causing it to never
> +>   drop to 0 and be freed.
> 
> How serious it is? Do you planning to MFC it to RELENG_4 with peter@'s
> patch of course?

A user can cause the kernel to allocate an unbounded amount of wired
memory, causing the machine to panic or stop responding. It's been observed
to happen under real workloads; that is, the circumstances are not so
contrived that the bug could only be caused by a malicious user.

I don't have any immediate plans to MFC it (I don't have any 4.x systems
right now), but peter@ or ps@ may want to after letting it settle for a
while in -current.


Tim

----- End forwarded message -----