CVE-2026-72422

CVE CVE-2026-72422EUVD EUVD-2026-59321Published 2026-08-15T05:56:41.000ZLast changed 2026-08-17T05:44:02.000ZCVSS 9.8

What the advisory describes

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 preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) 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 smb3_preauth_hash_rsp() under ksmbd_conn_lock(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. ksmbd_gen_preauth_integrity_hash() 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).

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 8a8315a5960bd2b5ffc75f44fc089e57c3b17c44; patch: 7.1.5; 5.19.2 <5.20; aa7253c2393f6dcd6a1468b0792f6da76edad917 <d0a469122e7bf8338fec1949fb1e8e1290ed8caa; patch: 0; aa7253c2393f6dcd6a1468b0792f6da76edad917 <1c89da3baa2b1f269178afa87dc30479b8535776; patch: 6.6.145; patch: 7.2; 5.18.18 <5.19; aa7253c2393f6dcd6a1468b0792f6da76edad917 <16a1ecf39c217e3d164bd32ef2a4f650abc067fa; 5.15.61 <5.15.212; patch: 6.1.178; aa7253c2393f6dcd6a1468b0792f6da76edad917 <7470511d085af1c7a043a60e53d52b512d5a10b1; patch: 5.15.212; 6.0; ff20f1875889dbe4a67c9298e609d7c88cf6456d; patch: 6.18.40; aa7253c2393f6dcd6a1468b0792f6da76edad917 <0c054227479ed7e36ebccb3a558bc0ef698264f6; dd4e4c811898410e6a3ae3b63207b7c542860907 <c7bef84740d1d57848c74f6f5b996606e43ea4fe; patch: 6.12.97; aa7253c2393f6dcd6a1468b0792f6da76edad917 <77bb0bbfcc4e777ca653174689e5e363f8ee63d1

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.