Bug #5318
closedPanic with smbtorture raw.scan-eamax
100%
Description
After running smbtorture raw.scan-eamax, we see a panic in smb_transact_secondary, with either NULL or 0xdeadbeef
Updated by Gordon Ross over 8 years ago
This is a use-after-free situation.
Analysis by Matt Barden:
0x836b814::whatis mdb: unable to readvar "umem_internal_arena": unknown symbol name 836b814 is 836b800+14, freed from umem_alloc_320: ADDR BUFADDR TIMESTAMP THREAD CACHE LASTLOG CONTENTS 83699f0 836b800 ad20ce5e966e 12 80a0a10 0 8082eb0 libumem.so.1`umem_cache_free_debug+0x13c libumem.so.1`umem_cache_free+0x43 libumem.so.1`umem_free+0xe2 libfakekernel.so.1`kmem_free+0x2e libfksmbsrv.so.1`smb_free+0x145 libfksmbsrv.so.1`smb_mem_free+0x2e libfksmbsrv.so.1`m_freem+0x7e libfksmbsrv.so.1`smb_request_free+0x202 libfksmbsrv.so.1`smb_session_worker+0x11b libfakekernel.so.1`taskq_thread+0x132 libc_hwcap1.so.1`_thrp_setup+0x9b libc_hwcap1.so.1`_lwp_start
When it panics, this is the chain it's trying to process:
print *mbc->chain *mbc->chain = { m_hdr = { mh_next = (nil) mh_nextpkt = (nil) mh_len = 32 mh_data = 0x82ab054 "ÿSMB3" mh_type = 1 mh_flags = 1 } M_dat = { MH = { MH_pkthdr = { len = 0 } MH_dat = { MH_ext = { ext_buf = 0x82ab054 "ÿSMB3" ext_ref = 0xfeef1c40 = &mclref() ext_size = 2048U } MH_databuf = "T�*\\b@\\034��" } } M_databuf = "" } }
that just so happens to be the same chain as sr->reply at that time. sr->reply seems to have an ext_size of (whether in trans2 secondary or not)
(dbx) print *sr->reply.chain *sr->reply.chain = { m_hdr = { mh_next = (nil) mh_nextpkt = (nil) mh_len = 32 mh_data = 0x82acc14 "ÿSMB2" mh_type = 1 mh_flags = 1 } M_dat = { MH = { MH_pkthdr = { len = 0 } MH_dat = { MH_ext = { ext_buf = 0x82acc14 "ÿSMB2" ext_ref = 0xfeef1c40 = &mclref() ext_size = 2048U } MH_databuf = "\\024�*\\b@\\034��" } } M_databuf = "" } }
Updated by Gordon Ross over 8 years ago
The implementation of the "Transact" and "Transact Secondary"
SMB request family (all three: RAP, Trans2, NT-Trans) all had
potential use-after-free situations caused by references to
the original "trans" request after that completes.
The straight-forward solution to this is to copy the data from
both trans and trans-secondary requests into the longer-lived
transaction object used for fragment reassembly.
Updated by Electric Monk over 8 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit 7f3ef643e446c82e27a9386991b140b128baf22c
commit 7f3ef643e446c82e27a9386991b140b128baf22c Author: Gordon Ross <gwr@nexenta.com> Date: 2014-11-29T20:44:19.000Z 5318 Panic with smbtorture raw.scan-eamax Reviewed by: Albert lee <trisk@nexenta.com> Reviewed by: Ilya Usvyatsky <Ilya.Usvyatsky@nexenta.com> Reviewed by: Kevin Crowe <kevin.crowe@nexenta.com> Reviewed by: Dan McDonald <danmcd@nexenta.com> Approved by: Robert Mustacchi <rm@joyent.com>