Project

General

Profile

Bug #10977

Windows 10 SMB client exhausts smbauth sockets

Added by Gordon Ross 9 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2019-05-14
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Customer reported a problem with SMB clients in WORKGROUP mode being unable to establish new connections to SMB shares. Existing SMB sessions already established haven't been affected. A quick look at smbd shows it has 256 auth sockets open and apparently can't open any more.

A HA service failover - or a simple restart of smb/server service would restore access, but a few weeks later the problem would reoccur: the smbauth sockets would be opened - and not closed - again, till the point when amount of smbauth sockets reaches 256 and no further requests to map SMB shares would succeed.

History

#1

Updated by Gordon Ross 9 months ago

  • Status changed from New to In Progress
#2

Updated by Gordon Ross 9 months ago

This situation occurs if a client does part of an SMB/SMB2 session setup sequence but never finishes that sequence and does not close the connection.
In that case, the smbd authsvc will time out its end of the auth socket, but there's nothing on the kernel side of that socket to detect that the auth service has closed the other side of it. The kernel won't notice that the socket peer closed until the next time it tries to read or write that socket, which won't happen unless we get another SMB request on the UID allocated for that "logging on" session.

The server needs to defend against this situation. Fix implements timeouts for user objects in "loggon on" state.

#3

Updated by Gordon Ross 9 months ago

  • Description updated (diff)
#4

Updated by Gordon Ross 9 months ago

Testing:

I've found a way to demonstrate this bug. The trick is, run smbtorture under debug, and put a breakpoint in the function that sends one smb session setup message. After it sends one message, just leave it stopped in the debugger (don't continue or kill).
At that point the server will have an smb_user_t object sitting indefinitely in state "logging_on".
Wait 45 sec. and verify that the server had cleaned up (destroyed) that object.
(mdb -k ::smblist)

Verified logging_on users transition to state logged_off

#5

Updated by Electric Monk 9 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit 8f70e16bf3f533fa0e164d0da06d00cffc63b9bb

commit  8f70e16bf3f533fa0e164d0da06d00cffc63b9bb
Author: Gordon Ross <gwr@nexenta.com>
Date:   2019-05-23T02:59:03.000Z

    10977 Windows 10 SMB client exhausts smbauth sockets
    Reviewed by: Matt Barden <matt.barden@nexenta.com>
    Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Also available in: Atom PDF