CVE-2026-31610

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc<br /> <br /> The kernel ASN.1 BER decoder calls action callbacks incrementally as it<br /> walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken<br /> [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates<br /> conn-&gt;mechToken immediately via kmemdup_nul(). If a later element in<br /> the same blob is malformed, then the decoder will return nonzero after<br /> the allocation is already live. This could happen if mechListMIC [3]<br /> overrunse the enclosing SEQUENCE.<br /> <br /> decode_negotiation_token() then sets conn-&gt;use_spnego = false because<br /> both the negTokenInit and negTokenTarg grammars failed. The cleanup at<br /> the bottom of smb2_sess_setup() is gated on use_spnego:<br /> <br /> if (conn-&gt;use_spnego &amp;&amp; conn-&gt;mechToken) {<br /> kfree(conn-&gt;mechToken);<br /> conn-&gt;mechToken = NULL;<br /> }<br /> <br /> so the kfree is skipped, causing the mechToken to never be freed.<br /> <br /> This codepath is reachable pre-authentication, so untrusted clients can<br /> cause slow memory leaks on a server without even being properly<br /> authenticated.<br /> <br /> Fix this up by not checking check for use_spnego, as it&amp;#39;s not required,<br /> so the memory will always be properly freed. At the same time, always<br /> free the memory in ksmbd_conn_free() incase some other failure path<br /> forgot to free it.