CVE-2026-52961

What it actually does

This is a race condition in the Linux kernel CephFS client extended-attribute handling path. The client calculates the required xattr blob size, then calls code that temporarily releases and reacquires the Ceph inode lock. During that window, an MDS capability grant can replace the cached xattr blob and increment its version. The stale precomputed size can then be used against the newer blob, triggering a kernel BUG_ON in __ceph_build_xattrs_blob(). The practical impact is a kernel oops/crash or node instability when CephFS xattr/capability activity hits the race; this is primarily an availability flaw, not a demonstrated privilege-escalation or code-execution issue.

Why it matters to the business

Systems using the Linux kernel CephFS client can unexpectedly crash or become unstable during normal or adversarial CephFS metadata activity, causing workload interruption, failed jobs, service downtime, and possible failover events. The issue is not currently listed in CISA KEV, has no reported ransomware use, and has a low EPSS score, so broad internet-scale exploitation is not indicated; however, organizations that rely heavily on CephFS for production storage should treat it as an operational resilience risk because a kernel crash can interrupt every workload on the affected node.

How an attack unfolds

An attacker would need a path to influence CephFS metadata activity seen by a vulnerable Linux client, such as authenticated access to a mounted CephFS filesystem or control over/compromise of CephFS metadata-server behavior. The attacker triggers xattr-related operations while the client is concurrently processing MDS capability grants. If the timing aligns, the client computes an xattr blob size, drops the inode lock, receives a newer MDS-provided xattr blob, and then resumes using stale sizing assumptions. That inconsistent state reaches __ceph_build_xattrs_blob() and trips a kernel BUG_ON, producing an invalid-opcode oops in the ceph-msgr workqueue. Depending on kernel configuration and workload state, the result can be process/workqueue failure, filesystem disruption, or a full host panic/reboot.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the CephFS fix for the stale xattr blob size race in __ceph_build_xattrs_blob(). Because no product-specific fixed versions were provided, use the relevant distribution kernel advisory/changelog and confirm it contains the patch titled similar to "ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size." Reboot into the fixed kernel after installation. Where immediate patching is not possible, reduce risk by avoiding or limiting CephFS mounts on critical nodes, restricting CephFS access to trusted users and workloads, limiting unnecessary extended-attribute-heavy operations, isolating Ceph monitor/MDS/client networks, and ensuring high-availability/failover capacity for systems that depend on CephFS. These mitigations reduce exposure but do not remove the vulnerable kernel code path.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version with uname -r and checking the installed kernel package changelog or vendor advisory for the Ceph xattr blob race fix. Ensure the host has actually rebooted into the patched kernel rather than only installing it. On systems that previously mounted CephFS, review kernel logs after normal CephFS activity to confirm there are no recurring BUG/Oops traces involving __ceph_build_xattrs_blob, ceph_check_caps, handle_cap_grant, or ceph_con_workfn. In a non-production test environment, CephFS regression testing such as the generic/642 xfstests case can be used to validate that the crash is no longer reproducible.

Typical attack path

1. Identify a Linux system mounting CephFS with a vulnerable kernel Ceph client.
2. Obtain a way to generate CephFS metadata and extended-attribute activity, or influence MDS capability grants received by the client.
3. Create concurrent xattr/capability churn so the client enters the xattr blob rebuild path while MDS updates arrive.
4. Win the race where the required blob size is computed before the cached xattr blob is replaced.
5. Trigger the BUG_ON in __ceph_build_xattrs_blob().
6. Cause a kernel oops, crash, reboot, or CephFS client disruption, resulting in denial of service.

How to detect it

Look for evidence of kernel crashes or oops events on systems using CephFS. Primary sources are journalctl -k, /var/log/kern.log, /var/log/messages, syslog, dmesg output, pstore/EFI pstore records, kdump/vmcore analysis, hypervisor reset logs, and centralized log aggregation. Focus on stack traces that include __ceph_build_xattrs_blob together with Ceph capability-processing functions such as handle_cap_grant, ceph_check_caps, ceph_handle_caps, mds_dispatch, ceph_con_process_message, or ceph_con_workfn. Correlate crash timing with CephFS mount activity, xattr-heavy workloads, metadata-server events, or unusual client/MDS message bursts. Because this flaw causes availability impact rather than leaving a stable file artifact, absence of filesystem IOCs does not prove absence of exploitation; kernel crash telemetry is the most reliable evidence.

• kernel BUG at fs/ceph/xattr.c
• __ceph_build_xattrs_blob
• Workqueue: ceph-msgr ceph_con_workfn
• Oops: invalid opcode
• __prep_cap
• ceph_check_caps
• handle_cap_grant
• ceph_handle_caps
• mds_dispatch
• ceph_con_process_message
• ceph_con_v2_try_read
• ceph_con_workfn
• process_message+0x16/0x1a0
• generic/642

What your security team should do

• Inventory Linux systems that mount CephFS and prioritize those running production, clustered, or high-availability workloads.
• Map each CephFS client to its running kernel version and vendor patch status.
• Patch and reboot CephFS client systems to a kernel containing the upstream/vendor fix, prioritizing nodes where unplanned reboot or filesystem disruption would be high impact.
• Until patched, restrict CephFS access to trusted users and workloads and avoid exposing CephFS client functionality to untrusted multi-tenant activity.
• Enable or verify crash capture and centralized kernel logging so any exploitation or recurrence is observable after a reboot.
• Search historical kernel logs and crash dumps for CephFS BUG/Oops signatures associated with this issue.
• Monitor vendor advisories because fixed package versions vary by distribution and kernel stream.