{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2026-43420 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-43420 is a medium-severity vulnerability in Linux kernel, published on 8 May 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-43420 and fix it if it is affected.\n\nWhat it is: CVE-2026-43420 is a medium-severity vulnerability in Linux kernel, published on 8 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-43420 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-43420/ (Markdown: https://insights.sbomify.com/CVE-2026-43420/index.md)","id":"CVE-2026-43420","markdown":"https://insights.sbomify.com/CVE-2026-43420/index.md","name":"CVE-2026-43420","record":{"aliases":["BELL-CVE-2026-43420","DEBIAN-CVE-2026-43420","GHSA-8frp-2m2w-wr4j","ROOT-OS-DEBIAN-11-CVE-2026-43420","ROOT-OS-UBUNTU-2204-CVE-2026-43420","ROOT-OS-UBUNTU-2404-CVE-2026-43420","UBUNTU-CVE-2026-43420"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel Ceph","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel's Ceph filesystem can cause an inode link count underrun, leading to a kernel warning and potential denial of service.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":4.7,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix i_nlink underrun during async unlink\n\nDuring async unlink, we drop the `i_nlink` counter before we receive\nthe completion (that will eventually update the `i_nlink`) because \"we\nassume that the unlink will succeed\".  That is not a bad idea, but it\nraces against deletions by other clients (or against the completion of\nour own unlink) and can lead to an underrun which emits a WARNING like\nthis one:\n\n WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68\n Modules linked in:\n CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655\n Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : drop_nlink+0x50/0x68\n lr : ceph_unlink+0x6c4/0x720\n sp : ffff80012173bc90\n x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680\n x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647\n x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203\n x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365\n x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec\n x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74\n x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94\n x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002\n x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8\n Call trace:\n  drop_nlink+0x50/0x68 (P)\n  vfs_unlink+0xb0/0x2e8\n  do_unlinkat+0x204/0x288\n  __arm64_sys_unlinkat+0x3c/0x80\n  invoke_syscall.constprop.0+0x54/0xe8\n  do_el0_svc+0xa4/0xc8\n  el0_svc+0x18/0x58\n  el0t_64_sync_handler+0x104/0x130\n  el0t_64_sync+0x154/0x158\n\nIn ceph_unlink(), a call to ceph_mdsc_submit_request() submits the\nCEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion.\n\nMeanwhile, between this call and the following drop_nlink() call, a\nworker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or\njust a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own\ncompletion).  These will lead to a set_nlink() call, updating the\n`i_nlink` counter to the value received from the MDS.  If that new\n`i_nlink` value happens to be zero, it is illegal to decrement it\nfurther.  But that is exactly what ceph_unlink() will do then.\n\nThe WARNING can be reproduced this way:\n\n1. Force async unlink; only the async code path is affected.  Having\n   no real clue about Ceph internals, I was unable to find out why the\n   MDS wouldn't give me the \"Fxr\" capabilities, so I patched\n   get_caps_for_async_unlink() to always succeed.\n\n   (Note that the WARNING dump above was found on an unpatched kernel,\n   without this kludge - this is not a theoretical bug.)\n\n2. Add a sleep call after ceph_mdsc_submit_request() so the unlink\n   completion gets handled by a worker thread before drop_nlink() is\n   called.  This guarantees that the `i_nlink` is already zero before\n   drop_nlink() runs.\n\nThe solution is to skip the counter decrement when it is already zero,\nbut doing so without a lock is still racy (TOCTOU).  Since\nceph_fill_inode() and handle_cap_grant() both hold the\n`ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this\nseems like the proper lock to protect the `i_nlink` updates.\n\nI found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using\n`afs_vnode.cb_lock`).  All three have the zero check as well.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"ceph: fix i_nlink underrun during async unlink","id":"CVE-2026-43420","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"race_condition","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"usb: gadget: f_ncm: Fix net_device lifecycle with device_move","id":"CVE-2026-43421"},"packages":[],"prev":{"headline":"ceph: fix memory leaks in ceph_mdsc_build_path()","id":"CVE-2026-43419"},"products":["Linux"],"published":"2026-05-08","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A race condition in the Linux kernel's Ceph filesystem can cause an inode link count underrun, leading to a kernel warning and potential denial of service.","url":"https://insights.sbomify.com/CVE-2026-43420/"}