UBUNTU-CVE-2026-43420
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.
02 / AFFECTED SOFTWARE
Affected packages
87 explicit affected versions
50 explicit affected versions
6 explicit affected versions
24 explicit affected versions
10 explicit affected versions
12 explicit affected versions
12 explicit affected versions
10 explicit affected versions
12 explicit affected versions
27 explicit affected versions
34 explicit affected versions
13 explicit affected versions
12 explicit affected versions
13 explicit affected versions
26 explicit affected versions
18 explicit affected versions
14 explicit affected versions
41 explicit affected versions
5 explicit affected versions
74 explicit affected versions
66 explicit affected versions
46 explicit affected versions
2 explicit affected versions
15 explicit affected versions
51 explicit affected versions
70 explicit affected versions
77 explicit affected versions
8 explicit affected versions
54 explicit affected versions
5 explicit affected versions
8 explicit affected versions
10 explicit affected versions
7 explicit affected versions
78 explicit affected versions
78 explicit affected versions
13 explicit affected versions
43 explicit affected versions
11 explicit affected versions
6 explicit affected versions
59 explicit affected versions
12 explicit affected versions
19 explicit affected versions
10 explicit affected versions
6 explicit affected versions
97 explicit affected versions
82 explicit affected versions
83 explicit affected versions
84 explicit affected versions
76 explicit affected versions
37 explicit affected versions
26 explicit affected versions
89 explicit affected versions
7 explicit affected versions
10 explicit affected versions
84 explicit affected versions
40 explicit affected versions
13 explicit affected versions
44 explicit affected versions
20 explicit affected versions
35 explicit affected versions
49 explicit affected versions
47 explicit affected versions
18 explicit affected versions
40 explicit affected versions
62 explicit affected versions
45 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
52 explicit affected versions
1 explicit affected versions
21 explicit affected versions
7 explicit affected versions
16 explicit affected versions
48 explicit affected versions
8 explicit affected versions
7 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
14 explicit affected versions
10 explicit affected versions
1 explicit affected versions
7 explicit affected versions
17 explicit affected versions
41 explicit affected versions
43 explicit affected versions
16 explicit affected versions
17 explicit affected versions
10 explicit affected versions
37 explicit affected versions
10 explicit affected versions
11 explicit affected versions
13 explicit affected versions
10 explicit affected versions
39 explicit affected versions
3 explicit affected versions
10 explicit affected versions
11 explicit affected versions
65 explicit affected versions
26 explicit affected versions
34 explicit affected versions
29 explicit affected versions
13 explicit affected versions
12 explicit affected versions
95 explicit affected versions
10 explicit affected versions
40 explicit affected versions
8 explicit affected versions
89 explicit affected versions
52 explicit affected versions
33 explicit affected versions
23 explicit affected versions
58 explicit affected versions
10 explicit affected versions
20 explicit affected versions
19 explicit affected versions
11 explicit affected versions
5 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
10 explicit affected versions
16 explicit affected versions
3 explicit affected versions
90 explicit affected versions
10 explicit affected versions
26 explicit affected versions
39 explicit affected versions
1 explicit affected versions
35 explicit affected versions
48 explicit affected versions
11 explicit affected versions
10 explicit affected versions
13 explicit affected versions
16 explicit affected versions
88 explicit affected versions
50 explicit affected versions
3 explicit affected versions
7 explicit affected versions
16 explicit affected versions
18 explicit affected versions
43 explicit affected versions
12 explicit affected versions
7 explicit affected versions
27 explicit affected versions
63 explicit affected versions
43 explicit affected versions
46 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
8 explicit affected versions
9 explicit affected versions
36 explicit affected versions
44 explicit affected versions
16 explicit affected versions
45 explicit affected versions
37 explicit affected versions
50 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
17 explicit affected versions
11 explicit affected versions
39 explicit affected versions
90 explicit affected versions
6 explicit affected versions
7 explicit affected versions
4 explicit affected versions
79 explicit affected versions
10 explicit affected versions
1 explicit affected versions
1 explicit affected versions
1 explicit affected versions
88 explicit affected versions
16 explicit affected versions
10 explicit affected versions
8 explicit affected versions
45 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
14 explicit affected versions
11 explicit affected versions
1 explicit affected versions
19 explicit affected versions
39 explicit affected versions
77 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/ce0123cbb4a40a2f1bbb815f292b26e96088639f
- https://git.kernel.org/stable/c/6d5fd8bb574bef039eb3b738e523870433a2aeb9
- https://git.kernel.org/stable/c/7db008e85a5d17b64bc5390b828bf457ae91a415
- https://git.kernel.org/stable/c/8975b85b0d45ca811ace6fac5907652f2310e5ac
- https://git.kernel.org/stable/c/9b31e88ac5623d15c8bc46f69dfe1d3b43a8f67c
- https://git.kernel.org/stable/c/aedd29386b23f3e1e6818943e11abfff2953732f
- https://git.kernel.org/stable/c/b3f5513141ecc6b277a8f7b7efe58a0cf9a5e859
- https://git.kernel.org/stable/c/ce0123cbb4a40a2f1bbb815f292b26e96088639f
- https://git.kernel.org/stable/c/fcc477a6e8856c8a42b3c9e171724d8d6dfadd06
- https://ubuntu.com/security/CVE-2026-43420
- https://ubuntu.com/security/notices/USN-8567-1
- https://ubuntu.com/security/notices/USN-8574-1
- https://ubuntu.com/security/notices/USN-8574-2
- https://ubuntu.com/security/notices/USN-8574-3
- https://ubuntu.com/security/notices/USN-8575-1
- https://ubuntu.com/security/notices/USN-8575-2
- https://ubuntu.com/security/notices/USN-8575-3
- https://ubuntu.com/security/notices/USN-8576-1
- https://ubuntu.com/security/notices/USN-8576-2
- https://ubuntu.com/security/notices/USN-8595-1
- https://ubuntu.com/security/notices/USN-8595-2
- https://ubuntu.com/security/notices/USN-8595-3
- https://ubuntu.com/security/notices/USN-8596-1
- https://ubuntu.com/security/notices/USN-8597-1
- https://ubuntu.com/security/notices/USN-8606-1
- https://ubuntu.com/security/notices/USN-8607-1
- https://ubuntu.com/security/notices/USN-8608-1
- https://ubuntu.com/security/notices/USN-8609-1
- https://ubuntu.com/security/notices/USN-8610-1
- https://ubuntu.com/security/notices/USN-8619-1
- https://ubuntu.com/security/notices/USN-8620-1
- https://ubuntu.com/security/notices/USN-8620-2
- https://ubuntu.com/security/notices/USN-8620-3
- https://ubuntu.com/security/notices/USN-8620-4
- https://www.cve.org/CVERecord?id=CVE-2026-43420