Project

General

Profile

Bug #5318

Panic with smbtorture raw.scan-eamax

Added by Gordon Ross over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2014-11-13
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

After running smbtorture raw.scan-eamax, we see a panic in smb_transact_secondary, with either NULL or 0xdeadbeef

History

#1

Updated by Gordon Ross over 5 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 = "" 
}
}
#2

Updated by Gordon Ross over 5 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.

#3

Updated by Electric Monk over 5 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>

Also available in: Atom PDF