On Sun, 17 Feb 2008, Jim Bryant wrote:
FYI: The system assigned kern/120781 to this bug report.
IMHO, a security advisory should be issued ASAP.
Thanks for the report, I'm sure your widely distributed e-mail will get
someone looking at it quickly. In the future if you run into an issue you
think might require a security advisory, consider e-mailing it privately to
[EMAIL PROTECTED] so that the release of patches can cooincide with
publication of the problem.
That said, this is probably more a candidate for an errata patch rather than a
security advisory -- security advisories are normally limited to local/remote
privilege escalation or serious remote denial of service. Local denial of
service problems occur in all operating systems I'm aware of with such
frequency that the world would be continuously innundated with advisories to
the point of rendering advisories useless if we did them every time someone
discovered a way users could crash the system. You need only watch the change
logs of the various open source kernels for the words "fix panic", "don't
dereference NULL pointer", "don't leak a lock...", etc, to get a sense of the
quantity of locally exercisable system bugs, many of which can lead to
reboots, hangs, or data loss, to see why. Hopefully this bug will get
resolved shortly, and then we can evaluate if an errata notice is necessary.
Robert N M Watson
Computer Laboratory
University of Cambridge
Jim Bryant wrote:
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause a
panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of "uname -a" on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb 10
21:13:39 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WAHOO-SMP i386
Note: I just cvsupped earlier, and no changes have been put into cvsup
that would fix this problem.
Full Description:
I was doing a reorganization of my filesystems, and since I do offline
installs, I keep a local distfiles collection (or did until yesterday when
this happened), and in the process, put all of the distfiles on their own
filesystem to be mounted under /usr/ports/distfiles.
All was fine until I rebooted.
On rebooting, I got a page fault panic on mount of the new distfiles
filesystem.
i booted again, got it again, booted again this time into single-user, and
did a fsck on the filesystem, and it only showed as being "dirty", but
otherwise had no problems in the eyes of fsck. booted again, instant
panic.
i booted an older 6.2 CD and mounted the filesystem fine. i then put that
filesystem the way it was by mkdir'ing a distfiles dir and mv'ing
everything into it, but on reboot it still paniced on mount.
only a newfs was able to enable the filesystem to be mounted.
today i did further research, thinking it had to do with the number of
files in the top-level filesystem directory, and found that to be true.
the short c program in the next section (how to repeat the problem)
contains this.
a second test shows that, after a newfs, if this done in any subdirectory
of that filesystem, the panic is averted, and all is well. apparently this
bug only effects top-level directories of a UFS2 filesystem.
I have not attempted this to a non-UFS2 filesystem.
IMHO, a security advisory should be released, since any user with write
access to ANY top level directory of ANY mounted filesystem (most systems
have /tmp as a world writable top level filesystem directory) can create a
panic situation requiring a newfs of the said filesystem. A malicious user
with root access can do this to /. Either way, on boot, or any attempt to
mount said filesystem on a running system, will cause a panic, which of
course will cause an unbootable system on reboot.
How to repeat the problem:
Compile and run the following as instructed:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i);
system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem, with
a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is flushed
to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
Fix to the problem if known:
newfs(8)
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
