[Bug 260111] NFS v4 server crash due to ACL handling

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 29 Nov 2021 11:18:59 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260111

            Bug ID: 260111
           Summary: NFS v4 server crash due to ACL handling
           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 #229786 text/plain
         mime type:

Created attachment 229786
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229786&action=edit
Crash in NFS server's nfsm_advance()  due to bad ACL attr.

nfsrv_dissectacl() doesn't set *aclsizep if nfsrv_skipace() returns an
error. But there are paths through the NFSATTRBIT_ACL code in
nfsv4_loadattr() in which attrsum += cnt despite nfsrv_dissectacl()
returning an error -- in which case cnt is never initialized or
contains junk from a previous attribute. As a result
attrsum can end up negative, so that nfsv4_loadattr()
calls nfsm_advance() at the end even though maybe it shouldn't.

Further, when nfsv4_loadattr() is called due to a client's VERIFY, and
the VERIFY contains an ACL attribute to compare, but the file has no
ACL, nfsrv_dissectacl() calls nfsrv_skipace(). nfsrv_skipace() skips
forward in the query by the client-supplied length of the "who"
string. If client specifies a huge length, nfsrv_skipace()'s call to
nfsm_advance() will leave nd->nd_md == 0. Then the call to
nfsm_advance() at the end of of nfsv4_loadattr() will crash when it
tries to use nd->nd_md.

I've attached a demo:

# uname -a
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #109
main-n250904-c4c468281fb6-dirty: Sun Nov 28 06:24:00 EST 2021    
rtm@xxx:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM  riscv
# cc fnfsd_7.c
# ./a.out
...
panic: Fatal page fault at 0xffffffc0002107a6: 0x00000000000010
cpuid = 0
time = 1638181422
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+0x154
panic() at panic+0x2a
page_fault_handler() at page_fault_handler+0x1ee
do_trap_supervisor() at do_trap_supervisor+0x76
cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x70
--- exception 13, tval = 0x10
nfsv4_loadattr() at nfsv4_loadattr+0x3efe
nfsrvd_verify() at nfsrvd_verify+0xd6
nfsrvd_dorpc() at nfsrvd_dorpc+0x154c
nfssvc_program() at nfssvc_program+0x5a4
svc_run_internal() at svc_run_internal+0x808
svc_run() at svc_run+0x1a8
nfsrvd_nfsd() at nfsrvd_nfsd+0x30e
nfssvc_nfsd() at nfssvc_nfsd+0x386
sys_nfssvc() at sys_nfssvc+0xd0
do_trap_user() at do_trap_user+0x206
cpu_exception_handler_user() at cpu_exception_handler_user+0x72
--- exception 8, tval = 0

-- 
You are receiving this mail because:
You are the assignee for the bug.