[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.