CVE-2026-31718
Last modified
CVE-2026-31718 is a critical-severity vulnerability rated 9.8/10 on the CVSS scale. 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().. EPSS estimates a 0.36% chance of exploitation in the next 30 days.
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().
Metrics
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Weakness Enumeration
Affected Software
| Vendor | Product | Versions | Update |
|---|---|---|---|
| Linux | Linux Kernel | >= 6.6.32, < 6.7 | — |
| Linux | Linux Kernel | >= 6.9, < 6.12.84 | — |
| Linux | Linux Kernel | >= 6.13, < 6.18.25 | — |
| Linux | Linux Kernel | >= 6.19, < 7.0.2 | — |
| Linux | Linux Kernel | 7.1 | Rc1 |
References
Timeline
- Published
- Last Modified
- Status
- Modified
Frequently Asked Questions
What is CVE-2026-31718?
How severe is CVE-2026-31718?
How do I fix CVE-2026-31718?
Are you affected by CVE-2026-31718?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
