CVE-2026-72422

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

ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE

conn->preauth_info is shared connection state (struct

preauthintegrityinfo, kmalloc-96) that is allocated and freed by the

SMB2 NEGOTIATE handler and read by the response send path.

smb2handlenegotiate() allocates conn->preauth_info, and on a

deassemblenegcontexts() failure kfrees it and sets it to NULL. Both the

allocation and the free/NULL happen under ksmbdconnlock(conn) (the

connection srv_mutex), which is held across the whole handler body.

The response send path smb3preauthhash_rsp(), called from the send:

block of _handleksmbdwork(), reads conn->preauthinfo and dereferences

conn->preauthinfo->PreauthHashValue (via

ksmbdgenpreauthintegrityhash()) without taking conn_lock. When a

client drives two SMB2 NEGOTIATE requests on the same connection, one

worker can free conn->preauth_info on the failing-negotiate path while a

concurrent send-path worker is reading it, producing a slab

use-after-free read (KASAN-confirmed).

The send-path read tested conn->preauth_info for NULL but raced with the

free that occurs between the NULL check and the dereference, so the NULL

guard alone does not close the window.

Serialize the NEGOTIATE-branch read in smb3preauthhash_rsp() under

ksmbdconnlock(conn) and re-check conn->preauth_info inside the lock.

Because the negotiate handler holds conn_lock across its kfree + NULL

assignment, a reader that also takes conn_lock either runs fully before

the allocation or fully after the NULL store, and can never observe the

freed-but-not-yet-NULLed pointer. ksmbdgenpreauthintegrityhash()

takes no locks itself (it only computes a SHA-512 over the buffer), so

no lock-ordering inversion is introduced, and conn_lock is a sleepable

mutex which is safe on this send path (it already performs network I/O).