Re: [BUG] ksmbd: no check that transform SessionId matches inner one on encrypted requests

[Tom Talpey <tom@talpey.com>]

On 9/26/2026 6:24 PM, Namjae Jeon wrote:
> On Sun, Sep 27, 2026 at 9:25 AM Tom Talpey <tom@talpey.com> wrote:
>>
>> On 9/25/2026 4:45 PM, Namjae Jeon wrote:
>>>> Suggested fix: compare the transform SessionId with the inner one
>>>> after decryption and drop the connection on mismatch. Happy to send
>>>> a patch if that approach sounds right.
>>> Thanks for the detailed report. Please send the patch to the mailing
>>> list and me.
>> I agree that there appears to be an issue, but it may need some more
>> analysis of MS-SMB2 section 3.2.5.1.1.1.
>>
>> This in particular.
>>> As I read MS-SMB2, the server is supposed to verify the two
>>> SessionIds match and treat a mismatch as a protocol error.
>>
>> MS-SMB2 does have explicit requirements that the server MUST check
>> for equality (and drop the connection if unequal), but there is one
>> SHOULD attached to a behavior note stating an exception that doesn't
>> seem appropriate. So there may be a document issue which should be
>> resolved before deciding.
>>
>> Some of us are at the SDC IOLab in Santa Clara this week, I'll bring
>> it up with the Microsoft folks here and report back.
> Thanks for looking into this. I’ll wait for your update!
I did get a chance to look into it and there were some hyperlink issues
with the behavior notes in the document I downloaded, which have been
fixed. MS-SMB2 was updated just yesterday!

The situation is interesting however. On the client side, any difference
in the encryption transform and message sessionid's is basically fatal
and the connection is broken.

On the server, the received sessionid can validly differ if the message
is an encrypted compound, in certain cases.

Section 3.3.5.2.1.1 says:

>  The server MUST verify if any of the following conditions are true and, if so, the server MUST
> disconnect the connection as specified in section 3.3.7.1:
>  For a singleton request and the first operation of a compounded request,
>  The size of the decrypted message is less than the size of the SMB2 Header
>  SMB2_FLAGS_RELATED_OPERATIONS is set in the Flags field of the SMB2 header of
> the request
>  The SessionId field in the SMB2 header of the request is not equal to
> Request.TransformSessionId.
>  In a compounded request, for each operation in the compounded chain except the first
> one, SMB2_FLAGS_RELATED_OPERATIONS is not set in the Flags field of the SMB2
> header of the operation and SessionId in the SMB2 header of the operation is not equal
> to Request.TransformSessionId.

Because I'm not sure what version of MS-SMB2 was referred to in the
fix comments, it would be good to re-verify against this text since it
may have changed.

Bottom line, the server must drop the connection on any mismatch for
singletons, and for the first operation in a compound. But subsequent
operations in the compound may differ if !RELATED, yet must fail if
not!

Tom.