[Bug 263043] malformed SMB reply can page-fault the kernel in smb_t2_placedata()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263043

            Bug ID: 263043
           Summary: malformed SMB reply can page-fault the kernel in
                    smb_t2_placedata()
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: rtm@lcs.mit.edu

Created attachment 232940
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232940&action=edit
fake SMB server that provokes a page-fault in the kernel smb client's
smb_t2_placedata()

If an SMB reply message claims a tiny offset for the data, placing the
data before the parameters, smb_t2_placedata() can page-fault on the
zero return value from a failing m_split(). This can occur on both
13.0-RELEASE-p8 and a recent CURRENT.

I've attached a demo that mounts a fake SMB server on /mnt; the server
generates a bad SMB reply at one point. That reply has data offset=4
count=68, params offset=56 count=10.


# uname -a
FreeBSD xxx 13.0-RELEASE-p8 FreeBSD 13.0-RELEASE-p8 #0: Tue Mar 15 09:36:28 UTC
2022    
root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64
# cc saxs1.c
# ./a.out
...
client #18 89
client #19 89
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x18
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff8231aef4
stack pointer           = 0x28:0xfffffe0063d87140
frame pointer           = 0x28:0xfffffe0063d87250
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 721 (a.out)
trap number             = 12
panic: page fault
cpuid = 0
time = 1649089759
KDB: stack backtrace:
#0 0xffffffff80c57525 at kdb_backtrace+0x65
#1 0xffffffff80c09f01 at vpanic+0x181
#2 0xffffffff80c09d73 at panic+0x43
#3 0xffffffff8108b1a7 at trap_fatal+0x387
#4 0xffffffff8108b1ff at trap_pfault+0x4f
#5 0xffffffff8108a85d at trap+0x27d
#6 0xffffffff81061d98 at calltrap+0x8
#7 0xffffffff82325189 at smbfs_findnext+0xa09
#8 0xffffffff82325453 at smbfs_smb_lookup+0xb3
#9 0xffffffff823219d7 at smbfs_getattr+0x67
#10 0xffffffff8231f3d0 at smbfs_node_alloc+0x270
#11 0xffffffff8231f0dc at smbfs_nget+0x6c
#12 0xffffffff8232122b at smbfs_lookup+0x4eb
#13 0xffffffff80cd776c at lookup+0x68c
#14 0xffffffff80cd6a87 at namei+0x487
#15 0xffffffff80cf78ae at kern_renameat+0xee
#16 0xffffffff8108baac at amd64_syscall+0x10c
#17 0xffffffff810626be at fast_syscall_common+0xf8

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