Skip to content
Fencer Vulns
medium 4.7

CVE-2026-43420 json

ceph: fix i_nlink underrun during async unlink

published 2026-05-08 6 mo ago modified 2026-11-06 3 d ago also EUVD-2026-28726

cvss
4.7
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.1%
EPSS 0.1% chance of exploitation in 30 days, percentile 0%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, 7.0
  • linux Debian 12 6.1.170-1
  • linux Debian 13 6.12.85-1
  • linux Debian 14 6.19.10-1

debian advisories DEBIAN-CVE-2026-43420

  • linux Ubuntu 22.04 LTS 5.15.0-186.196
  • linux Ubuntu 24.04 LTS 6.8.0-136.136
  • linux-aws Ubuntu 22.04 LTS 5.15.0-1112.119
  • linux-aws Ubuntu 24.04 LTS 6.8.0-1061.64
  • linux-gcp Ubuntu 22.04 LTS 5.15.0-1112.122
  • linux-gcp Ubuntu 24.04 LTS 6.8.0-1064.72
  • linux-gke Ubuntu 22.04 LTS 5.15.0-1108.114
  • linux-gke Ubuntu 24.04 LTS 6.8.0-1059.67

ubuntu advisories UBUNTU-CVE-2026-43420

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • cephfs SLE Module for Legacy 15 SP7 1.0-150700.15.7.1
  • kernel-64kb SLE Module for Basesystem 15 SP7 6.4.0-150700.53.66.1
  • kernel-syms SLE Module for Development Tools 15 SP7 6.4.0-150700.53.66.1
  • kernel-azure SLE Module for Public Cloud 15 SP7 6.4.0-150700.53.66.1
  • kernel-source SLE Module for Development Tools 15 SP7, SLE Module for Basesystem 15 SP7 6.4.0-150700.53.66.1
  • kernel-default SLE Workstation Extension 15 SP7, SLE Module for Legacy 15 SP7, SLE Module for Basesystem 15 SP7 +2 more 6.4.0-150700.53.66.1
  • kernel-zfcpdump SLE Module for Basesystem 15 SP7 6.4.0-150700.53.66.1
  • kernel-obs-build SLE Module for Development Tools 15 SP7 6.4.0-150700.53.66.1

suse advisories SUSE-SU-2026:5111-1SUSE-SU-2026:2800-1SUSE-SU-2026:2799-1SUSE-SU-2026:22522-1SUSE-SU-2026:22666-1SUSE-SU-2026:22521-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-43420 updated cvss 5.5

kernel: ceph: fix i_nlink underrun during async unlink

  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more
    affected: workaround, no fix available “To mitigate this issue, prevent the ceph module from being loaded. See https://access.redhat.com/solutions/41278 for instructions.”
  • Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    affected: workaround, no fix available, no fix planned “To mitigate this issue, prevent the ceph module from being loaded. See https://access.redhat.com/solutions/41278 for instructions.”
  • Red Hat Enterprise Linux 10 kernel
    affected: workaround, no fix available “To mitigate this issue, prevent the ceph module from being loaded. See https://access.redhat.com/solutions/41278 for instructions.”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
3 d ago

Exploit prediction

0.09% chance of exploitation in the next 30 days, higher than 0% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 4.7 CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Weakness
  • CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.