CVE-2026-43420: Linux Kernel Race Condition Vulnerability

CVE-2026-43420 Overview

CVE-2026-43420 is a race condition vulnerability in the Linux kernel's Ceph filesystem client. The flaw resides in the asynchronous unlink path, where the i_nlink inode counter is decremented before the Metadata Server (MDS) completion arrives. A concurrent worker thread processing CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT, or CEPH_MSG_CLIENT_REPLY messages can call set_nlink() to zero, after which ceph_unlink() decrements the counter again. This triggers a drop_nlink+0x50/0x68 WARNING at fs/inode.c:407 and corrupts inode link state. The issue affects systems mounting CephFS with async dirops enabled.

Critical Impact

A concurrency window between async unlink submission and completion handling allows the i_nlink counter to underflow, producing kernel warnings and inode state inconsistency on CephFS clients.

Affected Products

• Linux kernel CephFS client (fs/ceph) with async unlink enabled
• Linux kernel 6.14.11 and prior releases containing the async unlink code path
• Stable branches receiving fixes via commits 6d5fd8b, 7db008e, 8975b85, 9b31e88, aedd293, b3f5513, ce0123c, and fcc477a

Discovery Timeline

• 2026-05-08 - CVE-2026-43420 published to NVD
• 2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-43420

Vulnerability Analysis

The vulnerability is a Time-of-Check Time-of-Use (TOCTOU) race condition [CWE-367] in the CephFS client. During async unlink, ceph_unlink() calls ceph_mdsc_submit_request() to dispatch CEPH_MDS_OP_UNLINK to the MDS without waiting for the reply. The client then optimistically calls drop_nlink() under the assumption the unlink will succeed.

Between request submission and the local drop_nlink() call, a kernel worker thread may process an inbound MDS message. Handlers such as ceph_fill_inode() and handle_cap_grant() invoke set_nlink() with an authoritative count received from the MDS. If a parallel deletion by another client, or the completion of the current unlink, drives i_nlink to zero before the optimistic drop_nlink() executes, the subsequent decrement underflows the counter.

The underflow triggers the WARN_ON at fs/inode.c:407 in drop_nlink(), indicating illegal manipulation of a zero link count. Beyond the warning, the inode link count becomes inconsistent with server state.

Root Cause

The root cause is missing synchronization between the optimistic local drop_nlink() and asynchronous set_nlink() updates driven by MDS replies. The ceph_inode_info.i_ceph_lock spinlock protects set_nlink() in other paths but was not taken around the async unlink decrement, leaving the read-modify-write of i_nlink exposed to concurrent updates.

Attack Vector

The condition is reachable on any CephFS mount that exercises the async unlink path. A local unprivileged user issuing unlinkat() against files where the client holds the required capabilities can trigger the race when a second client deletes the same dentry, or when the MDS reply lands on a worker before the local decrement runs. The reporter reproduced the WARNING on unpatched 6.14.11 kernels under normal workload, confirming it is not theoretical.

The fix adds a zero check protected by i_ceph_lock, mirroring the pattern used in NFS, SMB (inode.i_lock), and AFS (afs_vnode.cb_lock). The decrement is skipped when i_nlink is already zero, eliminating the underflow.

Detection Methods for CVE-2026-43420

Indicators of Compromise

• Kernel warnings referencing drop_nlink+0x50/0x68 with a call trace through ceph_unlink, vfs_unlink, and do_unlinkat
• WARNING: CPU: ... at fs/inode.c:407 entries in dmesg or /var/log/kern.log on CephFS clients
• Inode link count discrepancies between CephFS clients and the MDS observed via stat or getfattr

Detection Strategies

• Parse kernel ring buffer output for drop_nlink warnings correlated with CephFS mount points and the ceph_unlink symbol
• Monitor for repeated unlinkat syscall activity from the same process immediately preceding kernel warnings
• Compare client-side i_nlink values with MDS-reported link counts during filesystem audits

Monitoring Recommendations

• Forward kernel logs from CephFS clients to a centralized logging pipeline and alert on fs/inode.c warnings
• Track CephFS client kernel versions across the fleet and flag hosts running pre-patch builds with async dirops enabled
• Audit MDS reply latency and worker thread scheduling delay, as elongated windows increase race exposure

How to Mitigate CVE-2026-43420

Immediate Actions Required

• Apply the upstream Ceph fix from one of the stable kernel commits: 6d5fd8b, 7db008e, 8975b85, 9b31e88, aedd293, b3f5513, ce0123c, or fcc477a
• Reboot CephFS clients into the patched kernel and validate the fs/ceph module reflects the fix
• Inventory CephFS client kernels and prioritize hosts with high unlink rates or multi-client write workloads

Patch Information

The fix wraps the decrement in ceph_unlink() with the ceph_inode_info.i_ceph_lock spinlock and skips drop_nlink() when i_nlink is already zero. See the upstream stable commits, including Kernel Git Commit 6d5fd8b, Kernel Git Commit 7db008e, Kernel Git Commit 8975b85, Kernel Git Commit 9b31e88, Kernel Git Commit aedd293, Kernel Git Commit b3f5513, Kernel Git Commit ce0123c, and Kernel Git Commit fcc477a.

Workarounds

• Disable the async dirops feature on affected CephFS mounts to force synchronous unlink behavior until kernels are patched
• Avoid concurrent deletions of the same dentry from multiple CephFS clients in workloads that cannot disable async unlink
• Suppress non-fatal impact by ensuring kernel panic_on_warn is not enabled on CephFS clients during the patch rollout window

# Remount CephFS without async dirops to bypass the affected code path
umount /mnt/cephfs
mount -t ceph <mon-addrs>:/ /mnt/cephfs -o name=admin,secretfile=/etc/ceph/admin.secret,wsync

# Verify the mount option is in effect
mount | grep cephfs