Re: How to take down a system to the point of requiring a newfs with one line of C (userland)

Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this.
The only top level file system I have that can be written to by normal users
is /tmp

Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from causing


On Feb 17, 2008 10:24 PM, Jim Bryant <freebsd@xxxxxxxxxxxxxxxxx> 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:

Environment (output of "uname -a" on the problem machine):
FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb
10 21:13:39 CST 2008
jbryant@xxxxxxxxxxxxxxxxx:/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

All was fine until I rebooted.

On rebooting, I got a page fault panic on mount of the new distfiles

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

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

Fix to the problem if known:

freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx

freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"