CVE-2026-43420

What it actually does

This is a race condition in the Linux kernel CephFS client during asynchronous unlink handling. The client submits an unlink request to the Ceph Metadata Server and, before completion is fully synchronized, may decrement the inode link count based on the assumption that the unlink will succeed. If a concurrent MDS reply, capability import, capability grant, or another client’s deletion updates the inode link count to zero first, the local client can call drop_nlink() on an inode whose i_nlink is already zero. The observed impact is a kernel WARNING in the Ceph unlink path; on systems configured to panic on WARN, this can become a local denial-of-service condition. The available information does not indicate memory corruption, privilege escalation, or remote unauthenticated code execution.

Why it matters to the business

Organizations using CephFS-backed workloads on affected Linux kernels may experience kernel warnings, service instability, or node crashes if kernel warning conditions are configured to trigger panics. The operational impact is most relevant for systems with high file deletion activity, shared CephFS access from multiple clients, web/application workloads using CephFS storage, build systems, cache directories, or other environments where many clients can delete the same or related files concurrently. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so urgency is primarily driven by CephFS usage and the business impact of node instability rather than broad active exploitation.

How an attack unfolds

An attacker or untrusted workload needs the ability to perform file deletions on a CephFS mount from an affected Linux client. The attacker repeatedly triggers unlink or unlinkat operations against files where asynchronous unlink behavior is possible, ideally while another client, worker thread, or MDS reply updates the same inode’s link count. If the timing is won, the kernel Ceph client receives or processes metadata updates that set the inode link count to zero before the original unlink path performs its local decrement. The subsequent drop_nlink() call attempts to decrement an already-zero counter, producing a kernel WARNING in the drop_nlink/ceph_unlink call path. On default systems this may only produce logs and instability symptoms; on hardened or debugging-oriented systems where panic_on_warn is enabled, the same condition may crash the node, causing denial of service for workloads running there.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel supplier that contains the CephFS fix for the asynchronous unlink i_nlink race. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories, stable kernel changelogs, or distribution security updates that reference this Ceph unlink fix. Prioritize systems that mount CephFS with write access, run high-delete workloads, or have kernel.panic_on_warn enabled. As temporary mitigations, restrict write/delete permissions on CephFS to trusted workloads, reduce highly concurrent deletion patterns where practical, isolate untrusted workloads from CephFS mounts, and consider disabling panic-on-warning behavior where consistent with operational policy to reduce the chance of a warning becoming a crash. These mitigations reduce exposure but do not correct the underlying kernel race.

How to confirm the fix worked

Confirm that the running kernel includes the CephFS async unlink link-count fix by checking the active kernel version with uname -r and comparing it to the distribution’s fixed kernel advisory or changelog. Validate that all CephFS client nodes, not only Ceph storage or MDS nodes, have been updated and rebooted into the fixed kernel. Review /proc/mounts or findmnt output to identify systems with CephFS mounts and verify they are running the remediated kernel. After patching, monitor dmesg, journalctl -k, and kernel logs during representative CephFS deletion workloads to ensure the drop_nlink/ceph_unlink WARNING no longer appears. If crash dumps were previously collected, confirm no new vmcore or kdump artifacts are generated from the same warning path.

Typical attack path

1. Obtain local code execution or application-level ability to create and delete files on a CephFS-mounted path.
2. Identify or generate a workload that causes frequent unlink/unlinkat operations on CephFS files.
3. Increase race likelihood by using concurrent deletion activity from multiple processes or multiple CephFS clients against overlapping file sets.
4. Trigger the affected asynchronous unlink path while Ceph MDS replies or capability updates are processed concurrently.
5. Cause the kernel client to update i_nlink to zero and then attempt an additional drop_nlink() decrement.
6. Observe kernel WARNING output, service disruption, or a node crash if panic-on-warning behavior is enabled.

How to detect it

To determine whether this condition has already occurred, review kernel logs rather than network telemetry. Primary sources are dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump metadata, kdump/vmcore records, and centralized syslog/SIEM copies of kernel logs. Look for WARNING entries with a call trace containing drop_nlink, ceph_unlink, vfs_unlink, do_unlinkat, or __x64_sys_unlinkat/__arm64_sys_unlinkat. Correlate timestamps with CephFS client activity, Ceph MDS logs, application logs showing high deletion rates, and auditd records for unlink/unlinkat syscalls on CephFS-mounted paths. If panic_on_warn is enabled, also investigate unexpected reboots, kernel panic records, watchdog resets, or vmcore files around the same time. There are no known public threat actors or ransomware campaigns associated with this issue in the supplied data, so detection should focus on evidence of the kernel warning, repeated triggering, and suspicious or untrusted workloads generating high-volume CephFS deletions.

• WARNING: CPU:
• at fs/inode.c:407 drop_nlink
• drop_nlink+
• ceph_unlink+
• vfs_unlink+
• do_unlinkat+
• __arm64_sys_unlinkat+
• __x64_sys_unlinkat+
• CEPH_MDS_OP_UNLINK
• CEPH_CAP_OP_IMPORT
• CEPH_CAP_OP_GRANT
• CEPH_MSG_CLIENT_REPLY
• Call trace:
• kernel.panic_on_warn = 1
• panic_on_warn

What your security team should do

• Inventory Linux systems that mount CephFS, especially those with write access or high-volume file deletion workloads.
• Patch and reboot affected CephFS client systems using vendor-supplied kernels that include the Ceph async unlink fix.
• Prioritize remediation for nodes where kernel.panic_on_warn is enabled, because the warning can become a service-impacting crash.
• Search historical kernel logs, system journals, and crash dumps for drop_nlink and ceph_unlink warnings to determine whether the race has already occurred.
• Restrict untrusted users, containers, and application workloads from writing to shared CephFS paths until affected clients are updated.
• Add temporary monitoring for repeated unlink/unlinkat activity against CephFS combined with kernel WARNING messages.
• Track distribution advisories for exact fixed kernel package versions because none were provided in the source data.