From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 627C53F0757 for ; Fri, 8 May 2026 14:26:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778250364; cv=none; b=IyEgE8JnxmPap/62hkQt4lXcbnBV6uCc6+6KZ92/bP4zj4ZjRsSvmjWUnS98WRlT3/fuwRRuvcQg/CPFTHqVOCDeF1Z0zz8QwzWYZRK8GbkLy5g6jSbVQZu/D7+UWllKMkjlUtYMagBVmZKSW+BAqjb+qUa/8OhgqMGQSYeZla8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778250364; c=relaxed/simple; bh=NzCmUYLWUWy+ZL0jsFUt3rcH9HlZg33FS/b9vORLouY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=hnN/WTLST/mrQRSvU9XsdqKf6pzlNhhslOuOQHjztdE3dSjGs+/lvFMYYVUvPpGziC1RZklGOU7OmFU+7bV7sboOnqiH4vT9C90LflJ8dMabxwygc4EGsak9CekqXGY5I/vnkGhRob+/ZlaTHirrgNBZ4dRlQh2NB5gkrrEm1Ew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=QVY2Ge7M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="QVY2Ge7M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A88D7C2BCB0; Fri, 8 May 2026 14:26:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1778250364; bh=NzCmUYLWUWy+ZL0jsFUt3rcH9HlZg33FS/b9vORLouY=; h=From:To:Cc:Subject:Date:Reply-To:From; b=QVY2Ge7MmmWy/bXgPaAp68cCLBqBzm+64aKWY/B1cHh+gPKuoY9CmnPIwwyvHi8/U bwoGrXLtncNaf4eJbdeZNQG0PHztft1WnNyLmKl0+LWmF47h+E5+Flwl7iZz42kbBt r8N3IddN/wf8vm54yArxKi6NQhUP/1x0LDNOWa20= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-43420: ceph: fix i_nlink underrun during async unlink Date: Fri, 8 May 2026 16:22:29 +0200 Message-ID: <2026050846-CVE-2026-43420-d121@gregkh> X-Mailer: git-send-email 2.54.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=6574; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=gRuJsbiSFaZThcduNCcMXmkmb9YdgnbZqTqgJb1aPv4=; b=owGbwMvMwCRo6H6F97bub03G02pJDJl/P1Zv27D8ZY9twezP4fM+hd66Va233b10dnIAT2bjx 4VyiyQfdMSyMAgyMciKKbJ82cZzdH/FIUUvQ9vTMHNYmUCGMHBxCsBE+n4wLJjiFK4wYc2FHo4W vwnVfxddWzTF8DvD/HSuhxr7Cp458bMcXur1z6C5eNKyZQA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman 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