CVE-2026-72044: ksmbd: fix stack buffer overflow in multichannel session-key copy

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix stack buffer overflow in multichannel session-key copy

Commit 4b706360ffb7 ("ksmbd: fix multichannel binding and enforce channel limit") moved the binding-path session key out of the session-wide sess->sesskey (CIFSKEYSIZE = 40) into a new per-channel buffer, and sized both that buffer and the on-stack copy used during binding with SMB2NTLMV2SESSKEYSIZE (16):

struct channel { char sesskey[SMB2NTLMV2SESSKEYSIZE]; / 16 / ... };

ntlmauthenticate() / krb5authenticate(): char channelkey[SMB2NTLMV2SESSKEYSIZE] = {}; / 16 / char authkey = conn->binding ? channelkey : sess->sesskey;

The two writers that fill this destination still bound the copy length against CIFSKEYSIZE (40), not against the 16-byte buffer:

ksmbddecodentlmsspauthblob() (NTLM key exchange): if (sesskeylen > CIFSKEYSIZE) / 40 / return -EINVAL; arc4crypt(ctxarc4, sesskey, (char )authblob + sesskeyoff, sesskeylen);

ksmbdkrb5authenticate(): if (resp->sessionkeylen > sizeof(sess->sesskey)) / 40 / ... memcpy(sesskey, resp->payload, resp->sessionkeylen);

On a binding SESSIONSETUP, authkey points at the 16-byte channelkey, so a client that supplies an NTLM EncryptedRandomSessionKey of up to 40 bytes (with NTLMSSPNEGOTIATEKEYEXCH), or a Kerberos ticket whose session key is longer than 16 bytes (a normal AES256 key is 32), writes past the 16-byte stack buffer -- up to a 24-byte kernel stack overflow. KASAN reports it as a stack-out-of-bounds write in arc4crypt() called from ksmbddecodentlmsspauthblob().

The destinations must be able to hold the full session key the length checks already permit. Size the per-channel key buffer and the two on-stack channelkey buffers with CIFSKEYSIZE, matching sess->sesskey.