CVE-2026-72381
CVE CVE-2026-72381EUVD EUVD-2026-59280Published 2026-08-15T05:56:13.000ZLast changed 2026-08-17T05:43:32.000ZCVSS 9.8
What the advisory describes
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d ("ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.
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 patch: 6.18.40; 00ce8d6789dae72d042a4522264964c72891ca37 <5a5ac2852cd326529d02f778bc1aa6184701f4d7; 49110a8ce654bbe56bef7c5e44cce31f4b102b8a <38637163501fd9e2f684b8cd275d0db5d79f37c6; 712cdf917e77a6444ce3836874829d770db20ee6 <fb978d72052704c6b06c6b0f129fcd60b77169f5; patch: 0; patch: 7.1.5; 6.18.25 <6.18.40; patch: 6.12.97; 7.0.2 <7.1; 6.12.92 <6.12.97; 6.6.142 <6.6.145; 7.1; c908c853f304a4969b5aa10eba0b50350cc65b80; c7f0f0d01c88bdcb8b1694d7d321670013f7ed7d <93d4d46bf9d442a12ea87278049ec416962c627f; 49110a8ce654bbe56bef7c5e44cce31f4b102b8a <ed98719be41389d416953b8ef9f07a07dfea6b2b; patch: 7.2; patch: 6.6.145
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
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage 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.