CVE-2026-89654: Linux kernel · ceph: fix UAF in check_new_map() on session freed during unlock
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 9.8 Critical · fixed in ee611a7509554c4ca1f54f6aefe592fb1df7ea70 : patch Linux kernel as a priority.
Data as of 26 Oct 2026, 13:47 UTC
- EPSS
- 0.6% chance of exploitation in 30 days – higher than 51% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers can reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in ee611a7509554c4ca1f54f6aefe592fb1df7ea70, 820871e9dbeecd2533c4c5f5d91878ceaf02324c, 9646dfee880730aae4b379a4b8ee6c88ac735acd +2
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 11 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: 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 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in check_new_map() on session freed during unlock check_new_map() iterates mdsc->sessions[] and for each active session drops mdsc->mutex to perform per-session operations. The forced-close path (rank removed from map) correctly takes a reference on s via ceph_get_mds_session() before releasing mdsc->mutex, but three other paths do not: Path A (address changed): mutex_unlock → mutex_lock(&s->s_mutex) Path B (reconnect): mutex_unlock → send_mds_reconnect(mdsc, s) Path C (active transition): mutex_unlock → mutex_lock(&s->s_mutex) Without the extra reference, another thread can acquire mdsc->mutex during the unlock window, call __unregister_session() which drops the last reference on s, and free it. The original thread then accesses freed memory via s->s_mutex. Fix by adding ceph_get_mds_session(s) before each mutex_unlock and ceph_put_mds_session(s) after the corresponding mutex_lock, matching the pattern already used in the forced-close path. Race timeline (Path A): Thread A (check_new_map) Thread B (another map update holds mdsc->mutex or session teardown) -------------------------- -------------------------- s = mdsc->sessions[i] (refcount == 1, held only by sessions[] array) mutex_unlock(&mdsc->mutex) ---> acquires mdsc->mutex __unregister_session(mdsc, s) sessions[i] = NULL ceph_put_mds_session(s) refcount: 1 -> 0 kfree(s) <--- freed! mutex_lock(&s->s_mutex) UAF on freed s->s_mutex
References
- git.kernel.org/stable/c/352a278d5a1965aae3f817ce5d24a67ee42d45d1 (opens in a new tab)
- git.kernel.org/stable/c/820871e9dbeecd2533c4c5f5d91878ceaf02324c (opens in a new tab)
- git.kernel.org/stable/c/9646dfee880730aae4b379a4b8ee6c88ac735acd (opens in a new tab)
- git.kernel.org/stable/c/21d5be092d947f8d83f76f7ebf3989e7e9230a98 (opens in a new tab)
- git.kernel.org/stable/c/ee611a7509554c4ca1f54f6aefe592fb1df7ea70 (opens in a new tab)