CVE-2026-52960

What it actually does

This is a Linux kernel CephFS client flaw in writeback handling. When the kernel gathers folios for writeback and then removes folios that are not suitable for writeback, it fails to drop the references held by the batch. Repeatedly reaching this path can leak folio references, preventing memory from being reclaimed and potentially causing kernel memory pressure, degraded I/O behavior, or denial of service. The issue is not described as enabling code execution, privilege escalation, or data disclosure.

Why it matters to the business

Systems using the Linux kernel CephFS client may become unstable or unavailable if the vulnerable writeback path is repeatedly triggered. The most likely operational impact is service degradation or outage on hosts that mount CephFS, especially file-serving, compute, container, or storage-adjacent workloads that rely on Ceph-backed filesystems. Current exploitation signals are low: EPSS is low, no known CISA KEV listing is present, and no public exploit maturity is indicated.

How an attack unfolds

An attacker would need a way to cause activity on a vulnerable Linux system using the CephFS client, typically by generating file I/O that drives dirty page or folio writeback. If the workload repeatedly causes folios to be selected and then removed as unsuitable for writeback, the kernel may retain references that should have been released. Over time, this can consume reclaimable memory and place pressure on the kernel memory manager. The likely end result is degraded performance, failed allocations, hung or killed processes, or host-level denial of service. Exploitation is expected to be workload- and configuration-dependent and most relevant where untrusted or semi-trusted users can generate significant CephFS write activity.

How to fix it

Upgrade the Linux kernel to a version that includes the CephFS writeback fix for this issue. Because no exact affected product list or fixed package versions were provided, use the fixed kernel packages from the operating system vendor or kernel distribution rather than attempting a manual source patch unless that is the normal operational model. Prioritize systems that mount CephFS, run storage-heavy workloads, or allow untrusted users or applications to write to CephFS. If immediate patching is not possible, reduce exposure by limiting who can write to CephFS mounts, applying workload quotas where available, monitoring memory pressure closely, and avoiding high-volume untrusted write workloads on vulnerable kernels.

How to confirm the fix worked

Confirm that the running kernel includes the vendor fix for the CephFS folio writeback reference handling issue. Validate both the installed kernel package and the actively booted kernel, since systems may have patched packages installed but still be running an older kernel until reboot. Check whether CephFS is in use by reviewing mounted filesystems and loaded kernel modules. After patching, run representative CephFS writeback-heavy workloads and monitor memory usage, slab/page-cache behavior, kernel logs, and OOM activity to confirm the leak no longer occurs.

Typical attack path

1. Identify a Linux host running a vulnerable kernel with CephFS mounted or otherwise using the kernel Ceph client.
2. Obtain the ability to create, modify, or delete files on the CephFS mount directly or through an application workflow.
3. Generate sustained file activity that causes dirty folios to enter the kernel writeback path.
4. Repeatedly trigger the code path where folios are removed from the writeback batch as unsuitable without their references being released.
5. Accumulate unreleased folio references until memory pressure, I/O stalls, process termination, or host instability occurs.

How to detect it

There are no known CVE-specific exploitation indicators or public exploit artifacts for this issue. To investigate possible prior exploitation or impact, review host telemetry from Linux systems using CephFS for unexplained memory growth, persistent page-cache or slab pressure, OOM killer events, process deaths, kernel allocation failures, hung tasks, and CephFS writeback anomalies. Useful sources include kernel logs, system journal logs, audit logs for high-volume file activity on CephFS mounts, endpoint telemetry, Ceph client logs if collected, and monitoring data for memory, swap, I/O wait, and filesystem write volume. Look for a temporal relationship between sustained CephFS write activity and increasing memory pressure or host instability. Because the expected outcome is denial of service rather than a durable compromise, absence of malware artifacts does not rule out abuse.

What your security team should do

• Inventory Linux systems that mount CephFS or load the Ceph kernel client.
• Prioritize kernel updates for CephFS clients that support production services, multi-user workloads, or untrusted file-write paths.
• Apply vendor-provided fixed kernel packages and reboot systems into the patched kernel.
• Where patching is delayed, restrict write access to CephFS mounts and apply operational controls to limit sustained high-volume write activity.
• Monitor affected hosts for memory pressure, OOM killer events, kernel warnings, I/O stalls, and CephFS-related instability.
• Because the vulnerability is not currently in KEV and has low EPSS, handle it as a reliability and availability patch priority rather than an active widespread exploitation emergency unless local exposure is high.