CVE-2026-80527: Linux Kernel Ceph Race Condition Vulnerability

CVE-2026-80527 Overview

CVE-2026-80527 is a denial-of-service flaw in the Linux kernel Ceph client. The vulnerability lets a reader thread hang indefinitely inside __ceph_get_caps() when local mds_wanted state becomes stale relative to what the Metadata Server (MDS) has actually observed. Under Ceph cap revocation scenarios, the reader can be left holding non-file caps while mds_wanted still records FILE_RD as wanted, causing try_get_cap_refs() to return zero and the caller to sleep on i_cap_wq forever.

Critical Impact
A remote workload interacting with CephFS can trigger conditions that stall reader threads indefinitely, producing sustained availability loss on affected Linux kernel clients.

Affected Products

Linux kernel with CephFS client (fs/ceph)
Multiple stable branches referenced by kernel.org commits 50958bb, 5e84bc6, 5fedf27, 9e55fe2, a3bc6b3, b566152, e05c315, and fcce1b3
Systems mounting CephFS through the in-kernel client

Discovery Timeline

2026-08-26 - CVE-2026-80527 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-80527

Vulnerability Analysis

The defect lives in the CephFS capability (cap) state machine. When another client performs a conflicting operation, the MDS revokes FILE_RD from the reader. A subsequent read must reacquire FILE_RD through a cap update message. The client tracks intent using cap->mds_wanted, which is updated inside __prep_cap() before the corresponding CEPH_MSG_CLIENT_CAPS message is queued for transmission.

This dual role for mds_wanted conflates two distinct states: what the client currently wants, and what the client believes the MDS already knows it wants. If the outbound cap update never reaches the MDS after cap->mds_wanted was raised, no further request is sent. The waiter then sleeps in __ceph_get_caps() until unrelated cap traffic happens to wake it.

Root Cause

The root cause is an ordering and semantics issue in the cap tracking logic. try_get_cap_refs() compares need <= mds_wanted and returns zero when the wanted set already covers the need, assuming an in-flight request will satisfy it. Because no state distinguishes "wanted locally" from "requested and observed by MDS", message loss or reconnect events can silently strand the request while the local state falsely indicates progress.

Attack Vector

Exploitation does not require authentication against the vulnerable node. Any workload that induces MDS cap revocation combined with a lost or unprocessed cap update can trigger the hang on the affected client. Refer to the kernel commit series listed in the Linux Kernel Commit 50958bb and Linux Kernel Commit fcce1b3 for the full technical trace.

No verified public exploit code is available. The vulnerability is described in prose in the upstream commit messages rather than through a reproducer.

Detection Methods for CVE-2026-80527

Indicators of Compromise

Reader threads stuck in D state with stacks pointing at __ceph_get_caps() and i_cap_wq.
CephFS workloads that stop making progress after MDS cap revocation events, without accompanying network partition symptoms.
Absence of expected CEPH_MSG_CLIENT_CAPS update messages following raised mds_wanted transitions.

Detection Strategies

Correlate kernel hung_task warnings against CephFS mount points and MDS session logs to identify stalled reader waiters.
Monitor MDS-side cap traffic for clients whose mds_wanted set diverges from their issued caps for extended periods.
Track distribution of read latency on CephFS clients and alert on outliers that never return.

Monitoring Recommendations

Enable hung_task_timeout_secs and forward the resulting warnings to a centralized log pipeline.
Capture kernel stack traces from processes in uninterruptible sleep to identify __ceph_get_caps() waits.
Alert on kernel versions of CephFS clients that do not yet include the fix commits referenced by the upstream advisory.

How to Mitigate CVE-2026-80527

Immediate Actions Required

Inventory all Linux hosts mounting CephFS and record their running kernel versions.
Deploy kernels that include the fix commits, starting with Linux Kernel Commit 5e84bc6 and the corresponding stable backports.
Reboot affected clients after patching to ensure the new cap-renewal logic is active.

Patch Information

The fix bounds the wait inside __ceph_get_caps() and falls back to a synchronous OPEN request through ceph_renew_caps() when the inode does not actually hold the wanted caps. It introduces CEPH_GET_CAPS_WAIT_TIMEOUT in mds_client.h and requires (issued & wanted) == wanted before taking the asynchronous ceph_check_caps() path. The change is distributed across the commits 50958bb, 5fedf27, 9e55fe2, a3bc6b3, b5661524, e05c315, and fcce1b3.

Workarounds

Where patching is not immediately possible, remount affected CephFS mounts to force cap state resynchronization when hangs are detected.
Reduce exposure by limiting concurrent conflicting workloads that trigger MDS-driven FILE_RD revocation on the same inodes.
Restart stalled reader processes after confirming hung task stacks trace back to __ceph_get_caps().

bash

# Confirm running kernel and CephFS mounts before and after patch deployment
uname -r
mount -t ceph
dmesg | grep -i "hung_task\|ceph"