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@freebsd.org>
----- Forwarded message from Tim Robbins <tjr@freebsd.org> -----
Date: Tue, 23 Mar 2004 21:53:10 +1100
From: Tim Robbins <tjr@freebsd.org>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/vm vm_map.c
Message-ID: <20040323105310.GA14855@cat.robbins.dropbear.id.au>
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 -----
