CVE-2026-43419

What it actually does

This vulnerability is a memory leak in the Linux kernel Ceph filesystem client path-building logic. In error paths within ceph_mdsc_build_path(), memory allocated for a pathname buffer via __getname() may not be released with __putname() unless ownership is successfully transferred to the caller. Repeatedly triggering those error paths can consume kernel memory over time, potentially degrading system stability or causing denial of service through memory pressure or out-of-memory conditions. There is no indication from the provided data that this enables code execution, privilege escalation, or data disclosure.

Why it matters to the business

Systems that mount or use CephFS through the affected Linux kernel client could experience degraded performance, instability, or outages if the leak is triggered repeatedly. The most likely operational impact is service disruption on workloads depending on Ceph-backed storage, including application errors, node instability, or forced process termination due to memory exhaustion. Current exploitation signals are low: EPSS is 0.00122, the issue is not in the CISA KEV catalog, is not known to be used in ransomware campaigns, and no public exploit maturity is reported; however, kernel-level denial-of-service flaws should still be addressed during normal kernel maintenance windows, especially on storage-heavy systems.

How an attack unfolds

An attacker would need a way to cause a vulnerable system to execute the affected CephFS client code path and repeatedly hit the specific error-handling branches in ceph_mdsc_build_path(). In practice, this would generally require local access to a system using the Ceph filesystem client, or influence over file operations performed against a CephFS mount. By repeatedly inducing failing path-construction operations, the attacker could cause small amounts of kernel memory to remain allocated. Over time, repeated triggering may increase memory pressure, causing system slowdown, allocation failures, out-of-memory killer activity, or service disruption. The provided intelligence does not indicate a remote unauthenticated exploit, active exploitation, named threat actors, or weaponized public exploit code.

How to fix it

Apply a Linux kernel update that includes the Ceph client fix adding the missing __putname() cleanup on affected error paths in ceph_mdsc_build_path(). Because no exact affected product list or fixed package versions were provided, use vendor advisories for the deployed distribution or kernel source tree to identify the corrected kernel build. Prioritize systems that mount CephFS or include the Ceph kernel client module. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting which services and users can interact with CephFS mounts, monitoring memory pressure on CephFS clients, and temporarily moving critical workloads away from vulnerable CephFS client nodes where operationally feasible. A reboot is typically required to fully replace a running vulnerable kernel after upgrading.

How to confirm the fix worked

Confirm the running kernel version is a vendor build that contains the upstream Ceph client memory-leak fix for ceph_mdsc_build_path(). Do not rely only on installed package inventory; verify the active kernel with runtime checks such as uname -r and distribution package metadata. On source-based or custom kernels, review the Ceph client code path to confirm error branches that allocate path using __getname() release it with __putname() unless ownership is transferred through path_info.path. Validate operationally by confirming CephFS clients remain stable under representative metadata/file-operation workloads and by checking that memory pressure does not grow abnormally during repeated error-condition testing. Also verify whether the ceph kernel module or built-in CephFS client is present and whether CephFS mounts are active; systems without CephFS usage are less exposed to practical exploitation.

Typical attack path

1. Identify a Linux system using the in-kernel CephFS client.
2. Obtain local access or influence an application/service to perform filesystem operations against a CephFS mount.
3. Trigger file or metadata operations that enter ceph_mdsc_build_path() and fail along affected error paths.
4. Repeat the operation many times to accumulate leaked kernel memory.
5. Cause increasing kernel memory pressure, leading to degraded performance, failed allocations, service interruption, or out-of-memory conditions.

How to detect it

To determine whether this issue may have been triggered, review Linux kernel logs and system telemetry from CephFS client systems for signs of abnormal memory growth, kernel allocation failures, OOM killer activity, and Ceph client errors around the same time. Useful sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, node memory metrics, Ceph client logs if collected, and EDR telemetry for local users or services repeatedly exercising CephFS paths. There may be no unique log entry for this specific leak, so detection is behavioral: look for repeated CephFS metadata/path-related failures followed by unexplained kernel memory pressure, increasing slab usage, process kills, or node instability. Correlate events with CephFS mount activity and user/application operations against mounted Ceph filesystems. Absence of these artifacts does not prove the vulnerability was never triggered, because memory leaks often leave only indirect system-stability evidence.

• ceph_mdsc_build_path
• Out of memory: Killed process
• invoked oom-killer
• oom-killer
• page allocation failure
• Memory allocation failure
• ceph:
• libceph:
• mds
• /sys/fs/ceph
• /proc/fs/ceph
• type ceph

What your security team should do

• Inventory Linux systems that mount CephFS or load/use the in-kernel Ceph client.
• Prioritize kernel updates on CephFS client nodes, especially production storage clients and systems running availability-sensitive workloads.
• Use vendor security advisories to map the fix to the exact kernel package version for each Linux distribution in use.
• After patching, reboot affected systems or otherwise ensure the fixed kernel is the one currently running.
• Monitor CephFS client nodes for memory pressure, OOM killer events, and repeated Ceph client errors until patching is complete.
• Restrict local user access and application write/metadata operation access to CephFS mounts where possible.
• Treat this as a maintenance-priority denial-of-service issue rather than an emergency internet-exposed remote-code-execution issue, given low EPSS, no KEV listing, no known ransomware use, and no reported exploit maturity.