Linux kernel CVE announcements
 help / color / mirror / Atom feed
* CVE-2026-43420: ceph: fix i_nlink underrun during async unlink
@ 2026-05-08 14:22 Greg Kroah-Hartman
  0 siblings, 0 replies; only message in thread
From: Greg Kroah-Hartman @ 2026-05-08 14:22 UTC (permalink / raw)
  To: linux-cve-announce; +Cc: Greg Kroah-Hartman

From: Greg Kroah-Hartman <gregkh@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.

The Linux kernel CVE team has assigned CVE-2026-43420 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 5.10.253 with commit 9b31e88ac5623d15c8bc46f69dfe1d3b43a8f67c
	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 5.15.203 with commit 6d5fd8bb574bef039eb3b738e523870433a2aeb9
	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 6.1.167 with commit fcc477a6e8856c8a42b3c9e171724d8d6dfadd06
	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 6.6.130 with commit b3f5513141ecc6b277a8f7b7efe58a0cf9a5e859
	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 6.12.78 with commit aedd29386b23f3e1e6818943e11abfff2953732f
	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 6.18.19 with commit 7db008e85a5d17b64bc5390b828bf457ae91a415
	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 6.19.9 with commit 8975b85b0d45ca811ace6fac5907652f2310e5ac
	Issue introduced in 5.7 with commit 2ccb45462aeaf0831397b90d31d3d50a7704fa1f and fixed in 7.0 with commit ce0123cbb4a40a2f1bbb815f292b26e96088639f

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-43420
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ceph/dir.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/9b31e88ac5623d15c8bc46f69dfe1d3b43a8f67c
	https://git.kernel.org/stable/c/6d5fd8bb574bef039eb3b738e523870433a2aeb9
	https://git.kernel.org/stable/c/fcc477a6e8856c8a42b3c9e171724d8d6dfadd06
	https://git.kernel.org/stable/c/b3f5513141ecc6b277a8f7b7efe58a0cf9a5e859
	https://git.kernel.org/stable/c/aedd29386b23f3e1e6818943e11abfff2953732f
	https://git.kernel.org/stable/c/7db008e85a5d17b64bc5390b828bf457ae91a415
	https://git.kernel.org/stable/c/8975b85b0d45ca811ace6fac5907652f2310e5ac
	https://git.kernel.org/stable/c/ce0123cbb4a40a2f1bbb815f292b26e96088639f

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2026-05-08 14:26 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-08 14:22 CVE-2026-43420: ceph: fix i_nlink underrun during async unlink Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox