DEBIAN-CVE-2026-72422

In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix use-after-free of conn->preauthinfo in concurrent SMB2 NEGOTIATE  conn->preauthinfo 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->preauthinfo, 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 srvmutex), which is held across the whole handler body.  The response send path smb3preauthhashrsp(), called from the send: block of handleksmbdwork(), reads conn->preauthinfo and dereferences conn->preauthinfo->PreauthHashValue (via ksmbdgenpreauthintegrityhash()) without taking connlock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauthinfo 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->preauthinfo 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 smb3preauthhashrsp() under ksmbdconnlock(conn) and re-check conn->preauthinfo inside the lock. Because the negotiate handler holds connlock across its kfree + NULL assignment, a reader that also takes connlock 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 connlock is a sleepable mutex which is safe on this send path (it already performs network I/O).