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

[Jim Bryant]

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     
jbryant at wahoo.sd67dfl.org:/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)

_______________________________________________
freebsd-security at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"