[Bug 260300] SECINFO_NO_NAME with PARENT and a file crashes NFS v4 server
Date: Fri, 10 Dec 2021 00:16:44 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260300 Bug ID: 260300 Summary: SECINFO_NO_NAME with PARENT and a file crashes NFS v4 server Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: rtm@lcs.mit.edu Attachment #230004 text/plain mime type: Created attachment 230004 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230004&action=edit Crash an NFS v4 server with a bad SECINFO_NO_NAME RPC. If the client sends a SECINFO_NO_NAME RPC with style=PARENT, and the current file handle refers to a file (not a directory), nfsrvd_secinfononame() calls nfsvno_namei() to look up ".." relative to that file. nfsvno_namei() returns ENOTDIR, and does not modify ni_startdir. But nfsrvd_secinfononame() calls vrele() on named.ni_startdir, which was never initialized. I've attached a demo. Exception 6 is a RISC-V mis-aligned atomic operation. # uname -a FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #141 main-n250910-5ebdc4cea5b6-dirty: Thu Dec 9 18:01:04 EST 2021 rtm@xxx:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM riscv # cc fnfsd_13.c # ./a.out ... panic: Unknown kernel exception 6 trap value ffffffc00025f562 --- exception 6, tval = 0xffffffc00025f562 atomic_fetchadd_32() at atomic_fetchadd_32+0x8 refcount_releasen() at refcount_releasen+0x1c refcount_release() at refcount_release+0xc vrele() at vrele+0x14 nfsrvd_secinfononame() at nfsrvd_secinfononame+0x120 nfsrvd_compound() at nfsrvd_compound+0xdc8 nfsrvd_dorpc() at nfsrvd_dorpc+0x294 nfs_proc() at nfs_proc+0x11a nfssvc_program() at nfssvc_program+0x426 svc_executereq() at svc_executereq+0xa2 svc_run_internal() at svc_run_internal+0x302 svc_run() at svc_run+0x146 nfsrvd_nfsd() at nfsrvd_nfsd+0x194 nfssvc_nfsd() at nfssvc_nfsd+0x300 sys_nfssvc() at sys_nfssvc+0xdc 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 -- You are receiving this mail because: You are the assignee for the bug.