Bug 206056

Created attachment 165290 [details]
Preventing a panic when pointers from struct ext2mount's um_e2fs are freed

On Linux I made a 500MB EXT4 filesystem for testing, and when I tried to mount it in FreeBSD with:

mdconfig -a /path/to/filesystem
mount -t ext2fs -o ro /dev/md0 /path/to/mountpoint

the following error got printed out, followed immediately by a panic:

ext2fs: no space for extra inode timestamps

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apicid = 00
fault_virtual_address = 0x4
fault code            = supervisor read, page not present
instruction pointer   = 0x20:0xc0b1f1cc
stack pointer         = 0x28:0xcebee898
frame pointer         = 0x28:0xcebee8c0
code segment          = base rx0, limit 0xfffff, type 0x1b
                      = DPL 0, pres 1, def32 1, gran 1
processor eflags      = interrupt enabled, resume, IOPL = 0
current process       = 777 (mount)
[ thread pid 777 tid 100065 ]
Stopped at      free+0x5c:    movl    0x4(%eax),%eax

db> bt
Tracing pid 777 tid 100065 td 0xc4e0c620
free(aa,c54ab298,2a3,2a1,0,...) at free+0x5c/frame 0xcebee8c0
ext2_mount(c4e16a80,c54ab208,c5374380,c4e10800,c4c40a70,...) at ext2_mount+0x1604/frame 0xceebe9e8
vfs_donmount(c4e4c620,1,0,c4c11b00,c4c11b00,...) at vfs_donmount+0xdc6/frame 0xceebebf0
sys_nmount(c4e0c620,ceebeca8,c506890c,c4e0c620,c506890c,...) at sys_nmount+0x78/frame 0xceebec18
syscall(ceebece8) at syscall+0x4a6/frame 0xceebecdc
Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xceebecdc
--- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x280e013b, esp = 0xbfbfdd20, ebp = 0xbfbfe278


The "ext2fs: no space for extra inode timestamps" message comes from compute_sb_data() in ext2_vfsops.c, which returns EINVAL after printing it, never reaching the subsequent lines that initialize fs->e2fs_gd and fs->e2fs_contigdirs. When ext2_mountfs() calls compute_sb_data(), it does a "goto out" on error, and in "out" it attempts to free() those 2 fields. Since the memory for the struct those fields are in wasn't initialized when it was allocated, free() is being passed invalid pointers, resulting in a panic.

The attached patch initializes the struct with those fields to zeroes on allocation, preventing the panic.

I'll investigate the original error that caused this buggy error path to be taken in a separate issue.