Linux Kernel CephFS EUVD-2026-80598

Requires a mounted CephFS filesystem using the in-kernel ceph client (6.10+, where mdsc->s_cap_auths and ceph_mds_check_access() exist) with MDS cap-based access checking active. A local process must be performing path/open operations (ceph_atomic_open path) at the exact moment an MDS session is being reopened, which replaces and frees the s_cap_auths array under mdsc->mutex. Limiting factors: exploitation is local-only (not remotely reachable despite the CVSS AV:N), needs a narrow timing window between the unlocked traversal and the session-reopen free (a race, so success is probabilistic), and requires local access to a host where CephFS is mounted - a deployment mode confined to Ceph storage environments.

The vendor-assigned CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N) is severely inflated and internally inconsistent with the vulnerability's own description. The upstream commit message shows this is a local, race-condition-driven use-after-free in the CephFS kernel client, NOT a network-reachable remote code execution: ceph_mds_check_access() traverses mdsc->s_cap_auths without holding mdsc->mutex while a concurrent MDS session reopen frees that array. The reproduced crash originates from a local file-open (ceph_atomic_open → path_openat → do_sys_openat2) by a local process (php-cgi in the trace), so the real attack vector is Local (AV:L), the trigger is a tight race window (AC:H), and it requires an unprivileged local user with access to a mounted CephFS (PR:L). The technical impact is a kernel oops/panic (denial of service), not the confidentiality/integrity compromise implied by C:H/I:H. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis.' Net: this is a moderate-severity local DoS (my independent estimate ~5.3), not the near-maximum-priority remote flaw the 9.8 suggests. The AV:N in the vector directly contradicts the description's call chain - verify with vendor/kernel maintainers; the actual reachability is local-only.

On a host with a mounted CephFS, a local unprivileged user repeatedly opens files (driving ceph_mds_check_access) while the MDS session is forced to reopen (e.g., network flap or MDS restart causing session OPEN handling to replace s_cap_auths). If the reopen frees the cap-auth array during a concurrent traversal, the kernel dereferences freed memory and oopses/panics, crashing the node. No public proof-of-concept is identified in the available data.