Project

General

Profile

Actions

Bug #14739

open

smbtorture disconnect after bad credit grant

Added by Gordon Ross 24 days ago. Updated 24 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

Description

Running smbtorture tests on a small VM with reduced max_credits (16) I saw many failures that were not in my "baseline" results (with default max_credits). The failures involve credit grants in async responses, where the server returns "status pending" to the client in an interim response, later followed by the final response for the request. An example failure is smb2.lock.async
as shown in the attached capture: lock-async-1.snoop where in frame 30, we've returned a credit grant of 0xFFF2, and then the client disconnected.


Files

lock-async-1.snoop (6.73 KB) lock-async-1.snoop Gordon Ross, 2022-06-12 02:22 PM
Actions #1

Updated by Gordon Ross 24 days ago

  • Status changed from New to In Progress

There's an underflow in the calculation of new credits here:
usr/src/uts/common/fs/smbsrv/smb2_dispatch.c around 392
in smb2_credit_increase()

    /*
     * If new credits would be above max,
     * reduce the credit grant.
     */
    if (cur > session->s_max_credits) {
        d = cur - session->s_max_credits;
        cur = session->s_max_credits;
        sr->smb2_credit_response -= d;        //  << underflow!
        DTRACE_PROBE1(smb2__credit__max, smb_request_t, sr);
    }

This seems to be only exposed when the session s_max_credits is clamped down,
but there is also a logic bug where we've failed to set the smb2_credit_response
in the earlier smb2_credit_decrease().

Actions #2

Updated by Electric Monk 24 days ago

  • Gerrit CR set to 2183
Actions #3

Updated by Gordon Ross 24 days ago

  • Description updated (diff)
  • Gerrit CR deleted (2183)
Actions #4

Updated by Gordon Ross 24 days ago

  • Gerrit CR set to 2183
Actions #5

Updated by Gordon Ross 24 days ago

Before fix:

$ smbtorture  -U ... //server/share smb2.lock.async
...
test: async
...
failure: async [
../../source4/torture/smb2/lock.c:849: status was NT_STATUS_INVALID_NETWORK_RESPONSE, expected NT_STATUS_OK: (../../source4/torture/smb2/lock.c:849)
]

after the fix, no errors
$ smbtorture -U ... //server/share smb2.lock.async
...
test: async
...
success: async

Actions #6

Updated by Gordon Ross 24 days ago

  • Description updated (diff)
Actions

Also available in: Atom PDF