CVE-2026-31718: Linux kernel · ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger
Affects Linux kernelSource GCVE Database
Not known to be exploited · CVSS 9.8 Critical.
Data as of 11 Nov 2026, 23:24 UTC
Contested
Critical score, yet low EPSS after six months · One scorer or none| CNA (Linux) | CVSS 3.1 | 9.8 |
|---|
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 29% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 1 May 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 11 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Linux Linux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().
References
- git.kernel.org/stable/c/0000a7780e0e446a28a273572f6ea8f7f582f694 (opens in a new tab)
- git.kernel.org/stable/c/e33c65f011980b4ad4abfd93585ec2079856368f (opens in a new tab)
- git.kernel.org/stable/c/3d6682726c2d3a46d31dae88b8166786b09b03ad (opens in a new tab)
- git.kernel.org/stable/c/b34fc42cfe922e551f7a27d3ac3bb016e41d7dd9 (opens in a new tab)
- git.kernel.org/stable/c/235e32320a470fcd3998fb3774f2290a0eb302a1 (opens in a new tab)