ksmbd signed SMB replies without checking the request
A peer who knew a session id could collect signatures made with another client's key, and related session errors could stall the connection.
Linux's in-kernel SMB server, ksmbd, signed some session-setup and error responses with a client's signing key without first checking that the request was genuine. Anyone who knew a session identifier could open a connection and collect signatures made with that key, a signing oracle that does not require holding the key.
Michail Andreas Michalopoulos posted fixes for those paths, after reports from Ian Bridges. The sharpest case is multichannel binding. ksmbd accepted a binding request once it saw the signed flag, then signed the "more processing required" reply with the session key, complete with a fresh NTLM challenge and at a message id of the sender's choice. The SMB2 specification requires the server to verify a binding request with the session signing key and to reject a bad signature before authentication proceeds. Reauthentication of a live session had the same hole: session setup was exempt from the generic signature check, so a forged signature still produced a response signed with the session key.
An expired Kerberos ticket opened a second oracle. ksmbd answered with a signed network-session-expired status before it had checked the message id or the signature. Because a Kerberos reauthentication keeps the session keys, that leak lasted for the rest of the session. The response is now signed only after both checks pass.
The same work stops ksmbd from always signing SMB 3.1.1 traffic with AES-CMAC. Negotiation could select HMAC-SHA256, but the server then overwrote that choice. It now keeps the algorithm that was negotiated and signs with the algorithm that belongs to the key in use.
Two further defects on failed sessions could take the connection down rather than leak signatures. Requests against an unknown, invalid, or expired session skipped the command sequence window, so message ids were never consumed and the window could fill until the connection stalled. Those same error replies never charged or granted credits, so a client whose session had expired could run out of credits before it managed to reauthenticate. Both are corrected, and the changes are marked for stable kernels.