CVE-2026-43408

What it actually does

This vulnerability is a Linux kernel memory-corruption flaw in the Ceph filesystem client. Some callers of ceph_mdsc_build_path() pass an uninitialized ceph_path_info structure and then call ceph_mdsc_free_path_info() after error handling. Because the structure may contain stale stack values, the kernel can attempt to free invalid or incorrectly typed memory, leading to slab allocator warnings, kernel BUG/Oops conditions, and system crashes. The reported impact is primarily local denial of service, but because the flaw involves unsafe kernel memory handling reachable by a low-privileged local user interacting with Ceph filesystem paths, privilege escalation cannot be ruled out without further exploitability analysis.

Why it matters to the business

Systems that mount or use CephFS with vulnerable Linux kernels may be exposed to local crashes triggered by unprivileged or low-privileged users, causing workload interruption, node instability, and possible service outages. If reliable privilege escalation techniques are developed, the impact could expand to full host compromise. The current public exploitation signal is low: EPSS is 0.00129, no known CISA KEV listing is present, no ransomware association is reported, and exploit maturity is listed as none; however, kernel memory-corruption issues should still be prioritized on multi-user systems and Ceph-backed production infrastructure.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system with sufficient ability to interact with a mounted Ceph filesystem. The attacker performs filesystem operations that reach affected Ceph client code paths, such as opening or resolving CephFS paths that cause ceph_mdsc_build_path() to fail. Because the ceph_path_info object was not consistently zero-initialized, subsequent cleanup may treat uninitialized memory as valid fields and pass bad pointers to kernel memory-freeing routines. In observed failure modes, this results in slab allocator corruption warnings followed by a kernel Oops or BUG, crashing the system or destabilizing the node. A more advanced exploit would attempt to shape stack or heap state so the invalid free behavior produces controlled kernel memory corruption, potentially enabling privilege escalation, though no mature public exploit is indicated by the provided data.

How to fix it

Upgrade to a Linux kernel version that includes the Ceph client fix adding missing ceph_path_info initializers. If using vendor kernels, apply the relevant distribution security update rather than relying only on upstream version numbers. No exact fixed versions were provided in the input, so administrators should consult their Linux distribution, appliance vendor, cloud image provider, or kernel maintainer advisories for the patched kernel build containing the fix for CVE-2026-43408. As interim mitigation, restrict local shell/container access on CephFS clients, limit which users and workloads can access mounted CephFS paths, avoid exposing CephFS mounts to untrusted workloads, and consider unmounting CephFS or moving workloads off affected kernels where patching cannot be performed promptly. Standard kernel hardening and rapid reboot recovery reduce operational impact but do not remove the vulnerability.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems that use the Ceph filesystem client and checking their running kernel versions against vendor advisories for the patched build. Validate remediation by booting into the updated kernel and confirming the old vulnerable kernel is no longer active with uname -a or equivalent fleet inventory tooling. Review whether CephFS mounts are present using mount, findmnt, or /proc/mounts and confirm that systems with CephFS exposure have been patched first. In test environments, reproduce only with safe negative-path CephFS operations and verify that the previously observed slab allocator warnings or kernel Oops conditions no longer occur. Also confirm that crash dumps and kernel logs remain clean after CephFS open/path-resolution activity.

Typical attack path

1. Obtain local access to a vulnerable Linux host, typically as a low-privileged user or through a workload running on the host.
2. Confirm that the host is running a vulnerable kernel with the Ceph filesystem client enabled and that CephFS is mounted or otherwise reachable.
3. Trigger CephFS path-handling operations that exercise affected ceph_mdsc_build_path() caller paths, especially error paths.
4. Cause ceph_mdsc_free_path_info() to run on a ceph_path_info structure that was not zero-initialized.
5. Induce invalid kernel memory-free behavior, leading to kernel warnings, Oops, BUG, panic, or node crash.
6. Optionally, if exploit techniques mature, attempt to control memory layout to convert the bug from denial of service into local privilege escalation.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, system journals, crash dumps, and monitoring alerts from Linux hosts using CephFS. Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, hypervisor reset events, and EDR telemetry that records kernel panics or abnormal reboots. Search for slab allocator warnings, invalid frees, kernel BUG/Oops messages, and stack traces containing Ceph client functions such as ceph_open, ceph_mdsc_build_path, ceph_mdsc_free_path_info, do_dentry_open, vfs_open, or path_openat. Correlate crashes with local user sessions, container workloads, batch jobs, or application activity accessing CephFS mounts shortly before the event. Because exploitation is local and may resemble an ordinary kernel crash, absence of network indicators does not rule out abuse. Repeated crashes on CephFS clients, especially tied to the same user, workload, container, or path activity, should be investigated as suspicious.

• virt_to_cache: Object is not a Slab page!
• cache_from_obj: Wrong slab cache. names_cache but object is from ceph_inode_info
• kernel BUG at mm/slub.c:634
• WARNING: CPU:
• kmem_cache_free
• __slab_free
• Oops: invalid opcode
• ceph_open+
• ceph_mdsc_build_path
• ceph_mdsc_free_path_info
• do_dentry_open+
• vfs_open+
• path_openat+
• ceph_inode_info
• names_cache
• /proc/mounts
• type ceph
• ceph

What your security team should do

• Prioritize patching Linux systems that mount CephFS, especially multi-user hosts, shared compute nodes, container hosts, and production storage clients.
• Use vendor-supplied kernel updates and ensure systems reboot into the patched kernel; merely installing a package is not sufficient if the old kernel remains running.
• Inventory CephFS usage across the fleet with configuration management, EDR, or osquery-style checks for ceph mounts and loaded ceph kernel modules.
• Temporarily restrict untrusted local users and workloads from interacting with CephFS mounts until patching is complete.
• Enable and retain kernel logs, crash dumps, and panic/Oops telemetry for affected systems to support post-incident review.
• Monitor for repeated kernel warnings or crashes containing Ceph client functions such as ceph_open, ceph_mdsc_build_path, or ceph_mdsc_free_path_info.
• Treat unexplained crashes on CephFS clients as potentially security-relevant even though current EPSS and exploit-maturity signals are low.
• If crashes are observed, preserve dmesg, journalctl -k output, vmcore/kdump files, and workload activity timelines before reboot cleanup removes evidence.