https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263662
Bug ID: 263662
Summary: kernel panics if fuse daemon returns parent's i-number
in FUSE_CREATE
Product: Base System
Version: Unspecified
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Attachment #233588 text/plain
mime type:
Created attachment 233588
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=233588&action=edit
fuse daemon that causes a panic by returning parent dir's i-number for
FUSE_CREATE
If a fuse daemon returns the parent directory's i-number for a new
file in FUSE_CREATE, the kernel notices that it is trying to acquire a
lock it already holds, and panics.
I've attached a demo:
# uname -a
FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n250917-440e36e68279: Fri
Apr 29 07:33:58 EDT 2022
rtm@xxx:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM2 riscv
# pkg install fusefs-libs
# cc -I/usr/local/include/fuse -o futo1a futo1a.c -L/usr/local/lib -lfuse
# ./futo1a
...
panic: lockmgr_xlock_hard: recursing on non recursive lockmgr
0xffffffd0012e5cb0 @ /usr/rtm/symbsd/src/sys/kern/vfs_subr.c:3023
cpuid = 0
time = 1649872295
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x38
kdb_backtrace() at kdb_backtrace+0x2c
vpanic() at vpanic+0x16e
panic() at panic+0x2a
lockmgr_xlock_hard() at lockmgr_xlock_hard+0xb4
lockmgr_lock_flags() at lockmgr_lock_flags+0x14e
vop_stdlock() at vop_stdlock+0x1c
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x32
VOP_LOCK1() at VOP_LOCK1+0x2e
_vn_lock() at _vn_lock+0x30
vget_finish() at vget_finish+0x48
vfs_hash_get() at vfs_hash_get+0xb6
fuse_vnode_alloc() at fuse_vnode_alloc+0x5c
fuse_vnode_get() at fuse_vnode_get+0x48
fuse_vnop_create() at fuse_vnop_create+0x300
VOP_CREATE_APV() at VOP_CREATE_APV+0x3a
VOP_CREATE() at VOP_CREATE+0x2e
vn_open_cred() at vn_open_cred+0x21e
kern_openat() at kern_openat+0x16a
sys_openat() at sys_openat+0x32
syscallenter() at syscallenter+0xf4
ecall_handler() at ecall_handler+0x18
do_trap_user() at do_trap_user+0xea
cpu_exception_handler_user() at cpu_exception_handler_user+0x72
--- exception 8, tval = 0xd12b67000
KDB: enter: panic
[ thread pid 35 tid 100051 ]
Stopped at breakpoint+0xa: c.ldsp s0,0(sp)
db>
--
You are receiving this mail because:
You are the assignee for the bug.
