CVE-2026-46052

What it actually does

This Linux kernel CephFS client flaw corrupts the VFS dentry hash list when Ceph re-adds a negative dentry that is already present in the primary dcache hash. The unsafe path can occur during Ceph lookup or atomic_open handling for nonexistent paths, specifically when d_add(dentry, NULL) is called on an already-hashed negative dentry. Once the hlist bucket is corrupted, lookups in __d_lookup() can loop indefinitely, causing CPU spin, RCU stall reports, hung tasks, degraded filesystem access, and potentially a node-level denial of service. The impact is availability-only; the vulnerability does not directly provide confidentiality or integrity compromise.

Why it matters to the business

Organizations using CephFS-backed workloads on affected Linux kernels may experience application stalls, high CPU consumption, stuck file operations, degraded storage access, or host instability. Because CephFS is commonly used for shared storage in web, compute, container, and data-processing environments, a triggered condition can affect many dependent applications at once. The CVSS score is high for availability impact, but current exploitation signals are limited: EPSS is low, the issue is not in CISA KEV, and no public exploit maturity is reported. Systems not mounting or using CephFS are not expected to be exposed to this specific flaw.

How an attack unfolds

An attacker first needs a reachable path that causes a vulnerable Linux system to perform CephFS pathname lookups or atomic open operations. This may be direct access to a service that stores or checks files on CephFS, or indirect access through an application that maps user-controlled names to CephFS paths. The attacker repeatedly requests nonexistent or rapidly changing filenames in directories where the Ceph client can reuse cached negative dentries. Under the vulnerable conditions, Ceph handles an ENOENT result or a local negative lookup fast path and calls d_add() even though the negative dentry is already hashed. That corrupts the dcache hash bucket, potentially creating a self-loop. Subsequent path lookups enter __d_lookup() and spin while walking the corrupted list, leading to RCU stalls, hung tasks, high CPU usage, and denial of service for the affected host or workload. There is no evidence from the supplied data that exploitation is being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the CephFS fix in fs/ceph/dir.c: only call d_add() for a negative dentry when d_unhashed() is true, and reuse already-hashed negative dentries as-is. No exact fixed package versions were provided in the input, so use the relevant distribution, appliance, cloud image, or kernel vendor advisory to identify the corrected kernel build. Prioritize systems that mount CephFS, run Ceph clients, host storage-intensive applications, or expose file lookup/open/stat behavior to untrusted users. If immediate patching is not possible, reduce exposure by limiting untrusted access to CephFS-backed paths, rate-limiting requests that generate large volumes of nonexistent file lookups, moving exposed workloads away from CephFS temporarily, and using operational monitoring to quickly reboot or fail over nodes showing RCU stalls. Generic kernel hardening will not fully mitigate this logic bug; applying the corrected kernel is the durable fix.

How to confirm the fix worked

Confirm exposure by verifying whether the host is running an affected kernel and whether CephFS is mounted or the ceph kernel client module is in use. Check mounted filesystems with commands such as findmnt -t ceph, mount | grep ceph, and lsmod | grep '^ceph'. Validate remediation by confirming the running kernel version matches a vendor-fixed build, then rebooting into that kernel if required. Review vendor changelogs or source patches for the CephFS dir.c change that gates d_add() on d_unhashed() for negative dentries. After patching, run representative CephFS workloads that perform lookup, stat, open, and atomic-create operations against nonexistent paths and monitor dmesg/journalctl for absence of RCU stalls, hung tasks, or __d_lookup stack traces. Confirm no hosts remain booted into older kernels after package installation.

Typical attack path

1. Identify or reach an application, service, or interface that causes the target Linux host to access CephFS paths.
2. Submit repeated requests involving nonexistent filenames, missing paths, or create/open/stat operations on CephFS-backed directories.
3. Cause the CephFS client to reuse cached negative dentries during lookup or atomic_open processing.
4. Trigger the vulnerable d_add(dentry, NULL) path on an already-hashed negative dentry.
5. Corrupt the VFS dentry hash bucket, potentially creating a self-loop in the hlist.
6. Force or wait for subsequent pathname lookups to enter __d_lookup() and spin indefinitely.
7. Degrade or deny service through CPU saturation, RCU stalls, hung file operations, and host/application instability.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, system journals, crash dumps, Ceph client logs, MDS logs, application access logs, and monitoring telemetry. The strongest host indicators are RCU stall or hung task reports with call traces involving __d_lookup, lookup_fast, walk_component, link_path_walk, path_lookupat, filename_lookup, vfs_statx, vfs_fstatat, or __do_sys_newfstatat on a system using CephFS. Correlate these events with high CPU on one or more cores, stuck processes performing filesystem operations, elevated ENOENT rates, repeated stat/open requests for nonexistent files, and application requests that target CephFS-backed paths. In Ceph telemetry, review client and MDS activity for abnormal lookup volume, repeated negative lookups, or bursts of missing-path operations before the stall. There are no unique attacker-controlled payload markers for this vulnerability, so detection should focus on kernel stall signatures plus correlated CephFS lookup behavior and request-source analysis.

• rcu: INFO: rcu_sched self-detected stall on CPU
• RCU stall
• self-detected stall on CPU
• __d_lookup+0x
• lookup_fast+0x
• walk_component+0x
• link_path_walk+0x
• path_lookupat+0x
• filename_lookup+0x
• vfs_statx+0x
• vfs_fstatat+0x
• __do_sys_newfstatat+0x
• do_syscall_64+0x
• NMI watchdog: BUG: soft lockup
• BUG: soft lockup - CPU
• INFO: task
• blocked for more than
• ceph_finish_lookup
• ceph_lookup
• fs/ceph/dir.c
• d_add(dentry, NULL)
• d_unhashed
• Comm: php-cgi
• type ceph
• findmnt -t ceph

What your security team should do

• Inventory all Linux systems that mount CephFS or load the Ceph kernel client and prioritize them for kernel updates.
• Patch or replace vulnerable kernels with vendor-fixed builds; ensure systems are rebooted into the corrected kernel, not merely updated on disk.
• Prioritize externally reachable or multi-tenant applications that perform user-influenced file operations on CephFS-backed storage.
• Add monitoring for kernel RCU stall, hung task, and __d_lookup stack traces on CephFS client hosts until remediation is complete.
• Review application logs and access patterns for bursts of requests for nonexistent files or paths mapped to CephFS, especially from unauthenticated or untrusted sources.
• If patching must be delayed, rate-limit or restrict untrusted path lookup/open/stat activity against CephFS-backed directories and consider moving exposed workloads to non-CephFS storage temporarily.
• Coordinate with storage and platform teams to validate kernel versions across base images, node pools, appliances, and container hosts that may inherit the vulnerable kernel.
• Treat repeated unexplained RCU stalls on CephFS clients as potential denial-of-service activity even though public exploitation and KEV status are currently not indicated.