CVE-2026-89654: ceph: fix UAF in check_new_map() on session freed during unlock
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix UAF in checknewmap() on session freed during unlock
checknewmap() 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 cephgetmdssession() before releasing mdsc->mutex, but three other paths do not:
Path A (address changed): mutexunlock → mutexlock(&s->smutex) Path B (reconnect): mutexunlock → sendmdsreconnect(mdsc, s) Path C (active transition): mutexunlock → mutexlock(&s->smutex)
Without the extra reference, another thread can acquire mdsc->mutex during the unlock window, call unregistersession() which drops the last reference on s, and free it. The original thread then accesses freed memory via s->smutex.
Fix by adding cephgetmdssession(s) before each mutexunlock and cephputmdssession(s) after the corresponding mutexlock, matching the pattern already used in the forced-close path.
Race timeline (Path A):
Thread A (checknewmap) Thread B (another map update holds mdsc->mutex or session teardown) -------------------------- -------------------------- s = mdsc->sessions[i] (refcount == 1, held only by sessions[] array)
mutexunlock(&mdsc->mutex) ---> acquires mdsc->mutex unregistersession(mdsc, s) sessions[i] = NULL cephputmdssession(s) refcount: 1 -> 0 kfree(s) <--- freed!
mutexlock(&s->smutex) UAF on freed s->smutex
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.57 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the Linux kernel Ceph check_new_map() paths, call ceph_get_mds_session(s) before each mutex_unlock(&mdsc->mutex), then call ceph_put_mds_session(s) after the corresponding mutex_lock; apply this to the address-changed, reconnect, and active-transition paths, matching the forced-close path.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects the Ceph code in the Linux kernel where metadata server sessions are processed during map updates. It is relevant to systems using that kernel Ceph functionality.
What must occur for the use-after-free to be triggered?
check_new_map() must release mdsc->mutex while handling an active session, and another thread must unregister and free that session during the unlock window. The original thread can then resume and access the freed session through s->s_mutex or related per-session operations.