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 -----
