detrunc()'s proc pointer argument may be passed to vinvalbuf(9), which
under certain conditions will pass the given proc pointer to
VOP_FSYNC(9), which always asserts that the given proc pointer is
equal to curproc.
msdosfs_write(), msdosfs_inactive(), createde(), and deextend() all
pass NULL for detrunc()'s proc pointer argument. I have no idea why.
If these detrunc() calls ever reach VOP_FSYNC(9) the kernel will
panic.
So, for example, any user with write access to an msdosfs partition
can panic the kernel by writing to the partition until they cause
ENOSPC. That particular panic looks like this:
panic: kernel diagnostic assertion "p == curproc" failed: file "/usr/src/sys/kern/vfs_vops.c", line 305
Stopped at db_enter+0xa: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
*500294 8955 0 0x100003 0 1K ksh
db_enter() at db_enter+0xa
panic(ffffffff81f1b0cf) at panic+0xc4
__assert(ffffffff81fa361c,ffffffff81ee8329,131,ffffffff81f7229b) at assert+0x3b
VOP_FSYNC(fffffd8449a78b30,ffffffffffffffff,1,0) at VOP_FSYNC+Oxd6
vinvalbuf(fffffd8449a78b30,3,ffffffffffffffff,0,0,ffffffffffffffff) at vinvalbuf+0xd5
detrunc(ffff80000186f900,1fe,0,ffffffffffffffff,0) at detrunc+0x239
msdosfs_write(ffff800055774b98) at msdosf_write+0x4a4
VOP_WRITE(fffffd8449a78b30,ffff800055774d10,3,fffffd8370e8d5d0) at VOP_WRITE+0x59
vn_write(fffffd83c723b860,ffff800055774d10,0) at vn_write+0xc0
dofilewritev(ffff8000556ecfc0,1,ffff800055774d10,0.ffff800055774dc0) at dofilewritev+0x14d
sys_write(ffff8000556ecfc0,ffff800055774dd0,ffff800055774dc0) at sys_write+0x6a
syscall(ffff800055774e70) at syscall+0x39b
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7ffffd8bf0, count: 2
This patch tweaks all the detrunc() calls in the aforementioned
msdosfs functions to pass curproc instead of a NULL pointer to
detrunc(). We don't appear to have curproc stashed anywhere in
msdosfs_write() or deextend(), so for those calls we explicitly pass
curproc.
This might have unforseen consequences I can't anticipate. However,
with this patch I can no longer panic the kernel by filling an msdosfs
partition, which seems like an improvement.
With advice from gnezdo@.
ok gnezdo@
19f38e0b6b