CVE-2026-52962

What it actually does

This is a Linux kernel memory-leak vulnerability in the Ceph filesystem client xattr handling path. During retries in __ceph_setxattr(), a previously allocated Ceph buffer referenced as old_blob may not be released with ceph_buffer_put(), allowing kernel memory to be leaked when extended attributes are repeatedly set on Ceph-backed files. The primary impact is local or workload-triggered denial of service through gradual memory exhaustion, potentially leading to degraded node performance, OOM-killer activity, process termination, or system instability. There is no indication from the provided data that this enables code execution or privilege escalation.

Why it matters to the business

Systems using CephFS through affected Linux kernels may become unstable or unavailable if the vulnerable xattr path is exercised repeatedly. In production environments, this can disrupt applications, storage workloads, container hosts, virtualization platforms, or clustered services that depend on Ceph-backed filesystems. The currently provided exploitation maturity is none, EPSS is low at 0.00139, and it is not listed in CISA KEV or associated with ransomware, so broad active exploitation is not indicated; however, the issue still matters for reliability-sensitive systems because denial-of-service flaws in kernel filesystem code can affect entire hosts.

How an attack unfolds

An attacker first needs a way to perform repeated extended-attribute operations against files on a Ceph-mounted filesystem. This may be possible through local shell access, a compromised workload, an application feature that writes file metadata, or a container with access to a CephFS mount. The attacker repeatedly invokes setxattr-style operations in a pattern that triggers the retry path in the Ceph client. Each successful trigger can leave a Ceph buffer reference unreleased in kernel memory. Over time, unreclaimed memory accumulates, reducing available kernel and system memory. Once memory pressure becomes severe, the host may slow down, kernel allocation failures may occur, the OOM killer may terminate unrelated processes, and services depending on the node may become unavailable. Because this is a resource-exhaustion issue, exploitation may look like abnormal metadata-heavy filesystem activity rather than a conventional exploit payload.

How to fix it

Apply a Linux kernel update that contains the upstream Ceph client fix for the __ceph_setxattr() buffer leak. Because no product-specific affected-version or fixed-version list was provided, use the kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer once they incorporate the fix. Prioritize systems that mount CephFS, especially shared application hosts, container nodes, storage gateways, and virtualization infrastructure. If immediate patching is not possible, reduce exposure by restricting who can write to CephFS mounts, limiting untrusted workloads with CephFS access, applying filesystem permission controls, using container isolation, monitoring or rate-limiting extended-attribute-heavy workloads where feasible, and ensuring nodes have memory pressure alerting and safe failover capacity. A reboot is typically required after installing a fixed kernel package unless the environment uses a supported live-patching mechanism that includes this fix.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems that mount CephFS and identifying their running kernel versions with uname -a or distribution package tools. Verify remediation by confirming the running kernel package includes the vendor fix for this CVE or the upstream patch that releases old_blob with ceph_buffer_put() in __ceph_setxattr(). Check that the host has actually booted into the fixed kernel after patching. Operationally validate by reviewing dmesg, journalctl -k, and monitoring data for reduced kernel memory growth during representative xattr-heavy CephFS workloads. Where safe in a non-production test environment, reproduce a controlled extended-attribute workload against a CephFS mount before and after patching and confirm that memory usage no longer grows abnormally over repeated operations.

Typical attack path

1. Identify a Linux host or workload with access to a CephFS mount using an affected kernel.
2. Obtain a means to create or modify files on that Ceph-backed filesystem, such as local access, a compromised service account, or an application upload/metadata path.
3. Repeatedly perform extended-attribute writes using setxattr, lsetxattr, fsetxattr, setfattr, or application-equivalent calls.
4. Trigger the retry path in the Ceph client where old_blob is not released properly.
5. Continue the operation until leaked kernel memory causes memory pressure, allocation failures, OOM-killer events, service crashes, or node instability.

How to detect it

To determine whether this was already exploited or triggered, focus on CephFS client hosts. Review kernel logs with dmesg and journalctl -k for OOM-killer activity, memory allocation failures, Ceph client errors, and instability around Ceph-mounted paths. Review auditd, eBPF, Sysmon for Linux, or EDR telemetry for unusually high volumes of setxattr, lsetxattr, fsetxattr, removexattr, or setfattr activity targeting CephFS mount points. Correlate spikes in extended-attribute writes with steadily increasing memory usage, slab growth, kernel memory pressure, process kills, or node reboots. Check application logs for metadata-heavy operations, repeated file attribute changes, upload processing loops, backup/indexing tools, or container workloads repeatedly modifying xattrs. There are no known public exploit-specific payload strings from the provided data, so detection should be behavioral: abnormal xattr syscall volume on CephFS plus unexplained kernel memory growth or OOM events.

• __ceph_setxattr
• ceph_buffer_put
• setxattr
• lsetxattr
• fsetxattr
• setfattr
• removexattr
• Out of memory: Killed process
• invoked oom-killer
• page allocation failure
• Memory allocation failure
• ceph:
• type=SYSCALL msg=audit
• syscall=setxattr
• syscall=lsetxattr
• syscall=fsetxattr

What your security team should do

• Inventory Linux systems with mounted CephFS and prioritize them for kernel update validation.
• Track distribution and vendor advisories for the fixed kernel package because exact fixed versions were not provided in the input.
• Patch or live-patch affected CephFS clients, then reboot or otherwise confirm the fixed kernel is running.
• Restrict CephFS write access for untrusted users, containers, and applications until remediation is complete.
• Monitor CephFS clients for unusual extended-attribute activity, sustained memory growth, OOM-killer events, and kernel allocation failures.
• Review application and workload behavior that performs large volumes of file metadata or xattr updates on CephFS.
• Because EPSS is low and there is no KEV listing or known exploitation maturity, handle this as a reliability and availability risk rather than an emergency internet-wide exploitation event unless local exposure is high.