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

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

[Dairui Zhang]

Hi,

I can't find any place where ksmbd checks that the SessionId in the
encryption transform header matches the SessionId in the decrypted
SMB2 header, and the two are used for different things:

  - the decryption key is selected by the transform SessionId:
    ksmbd_crypt_message() -> ksmbd_get_encryption_key(work,
    le64_to_cpu(tr_hdr->SessionId), ...) (auth.c:849)
  - the session that authorizes the request is selected by the
    decrypted inner header: smb2_check_user_session() ->
    ksmbd_session_lookup_all_states(conn,
    le64_to_cpu(req_hdr->SessionId)) (smb2pdu.c:938)

The only reader of tr_hdr->SessionId in the server directory is the
key lookup itself. And since encrypted requests are exempt from the
signing requirement (server.c:144), a valid AEAD tag is the only
proof of session identity - but it is checked against the wrong
session.

So on a connection carrying more than one session, a client can send
a request whose transform header names session A (decrypts with A's
key) while the inner header names session B. The command executes
with B's identity, tree connects and handles. The response is
encrypted with B's key (or sent plaintext if B's session has no enc
flag), so the sender learns nothing from it - but the write has
already happened as B.

The case I have in mind is a cifs multiuser mount, where one TCP
connection legitimately carries sessions of several users: a local
user with their own session key could act as another user on the same
connection. Session ids are allocated sequentially from 1
(ksmbd_ida.c:18), so they look enumerable. On a one-session-per-
connection setup I don't think this gains an attacker anything -
please correct me if I'm wrong.

As I read MS-SMB2, the server is supposed to verify the two
SessionIds match and treat a mismatch as a protocol error.

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.

This is my first report to this list, and it's from code reading
only - if I've misread the flow somewhere, please tell me.

Thanks,
Dairui Zhang

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

[Namjae Jeon]

> 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.

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

[Tom Talpey]

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.

Tom.

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

[Namjae Jeon]

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!

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

[Tom Talpey]

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.