CVE-2026-43420
Received Received - Intake
Link Underflow in Ceph Linux Kernel

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: ceph: fix i_nlink underrun during async unlink During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because "we assume that the unlink will succeed". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the "Fxr" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
ceph ceph *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's Ceph filesystem implementation during an asynchronous unlink operation. The issue arises because the inode link count (`i_nlink`) is decremented before the unlink operation completes, under the assumption that the unlink will succeed. However, this can race with other client deletions or the completion of the unlink itself, potentially causing the `i_nlink` counter to underrun (go below zero), which is illegal and triggers a kernel warning.

Specifically, the unlink request is submitted asynchronously to the Metadata Server (MDS) without waiting for completion. Meanwhile, other operations may update the `i_nlink` counter to zero. If the unlink code then decrements it further, it causes an underrun and a warning. The fix involves skipping the decrement when the counter is already zero and protecting the update with a proper lock to avoid race conditions.


How can this vulnerability impact me? :

This vulnerability can cause kernel warnings and potentially unstable behavior in the Ceph filesystem due to illegal decrements of the inode link count. While it does not directly indicate data corruption or security breach, the race condition and warnings could lead to filesystem inconsistencies or unexpected errors during file unlink operations in environments using Ceph.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a WARNING message in the Linux kernel logs related to the i_nlink counter underrun during async unlink operations in Ceph. To detect it, you should monitor your system logs for warnings similar to the following:

  • WARNING: CPU: <cpu_id> PID: <pid> at fs/inode.c:407 drop_nlink+0x50/0x68
  • Messages referencing ceph_unlink and drop_nlink functions in the call trace.

You can use commands like the following to search for such warnings in your system logs:

  • sudo dmesg | grep -i 'drop_nlink'
  • sudo journalctl -k | grep -i 'drop_nlink'
  • sudo grep -r 'drop_nlink' /var/log/

These commands help identify kernel warnings related to the i_nlink underrun issue caused by async unlink in Ceph.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is caused by a race condition in the Ceph async unlink code that leads to an illegal decrement of the i_nlink counter. The fix involves skipping the decrement when the counter is already zero and protecting the update with the appropriate spinlock.

Immediate mitigation steps include:

  • Update your Linux kernel to a version that includes the fix for this vulnerability, as it involves changes to the Ceph unlink handling code.
  • Monitor your system logs for the WARNING messages indicating the issue to detect if the vulnerability is being triggered.
  • Avoid forcing asynchronous unlink operations in Ceph until the fix is applied.

Since the issue is a race condition in kernel code, applying the patch or upgrading the kernel is the most reliable mitigation.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart