{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98581 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98581 is a vulnerability in Linux, published on 18 Oct 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-98581 and fix it if it is affected.\n\nWhat it is: CVE-2026-98581 is a vulnerability in Linux, published on 18 Oct 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-98581 in the wild and no public exploit code.\n\nAffected product: Linux. 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-98581/ (Markdown: https://insights.sbomify.com/CVE-2026-98581/index.md)","id":"CVE-2026-98581","markdown":"https://insights.sbomify.com/CVE-2026-98581/index.md","name":"CVE-2026-98581","record":{"aliases":["AZL-108833","BELL-CVE-2026-98581","DEBIAN-CVE-2026-98581","GHSA-h227-88m5-f744","UBUNTU-CVE-2026-98581"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel NFC","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel NFC LLCP handler allows local attackers to cause memory exhaustion and denial of service via list corruption.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()\n\nnfc_llcp_recv_dm() handles DM(NOBOUND)/DM(REJ) for a socket that is still\nlinked on local-\u003econnecting_sockets: it looks the socket up with\nnfc_llcp_connecting_sock_get(), sets sk-\u003esk_state = LLCP_CLOSED and\nreturns, without taking the socket lock and without unlinking the socket\nfrom the connecting_sockets list.\n\nllcp_sock_release() selects the list to unlink from by sk_state: a socket\nin LLCP_CONNECTING is unlinked from connecting_sockets, otherwise from the\nsockets list.  Because recv_dm left the socket physically on\nconnecting_sockets but in the LLCP_CLOSED state, release() takes the else\nbranch and calls nfc_llcp_sock_unlink(\u0026local-\u003esockets, sk).  That runs\nsk_del_node_init() while holding sockets.lock, i.e. it removes the socket\nfrom the connecting_sockets hlist under the wrong lock.  A concurrent\nconnect() linking another socket onto connecting_sockets under\nconnecting_sockets.lock then mutates the same hlist unserialized, which\ncorrupts the list and desyncs the sk_add_node()/sk_del_node_init()\nsock_hold()/__sock_put() pairing.  An unprivileged local process holding\nLLCP sockets, with the DM supplied by the remote peer over an established\nLLCP link, can drive this to leak kernel sockets without bound (the\nmis-decrement goes through the non-freeing __sock_put() path, so the\nobject is never released), leading to memory exhaustion / DoS.\n\nThis is the same class of bug that was fixed in the sibling handler\nnfc_llcp_recv_cc() by commit b493ea2765cc (\"nfc: llcp: Fix use-after-free\nrace in nfc_llcp_recv_cc()\"); recv_dm did not receive the equivalent fix.\n\nFix it the same way: take lock_sock(), re-check that the socket is still\nhashed (release() may have won the race), and for the NOBOUND/REJ case\nunlink it from connecting_sockets before moving it to LLCP_CLOSED.  The\nunlink drops the connecting_sockets membership reference via\nsk_del_node_init(), leaving the socket unhashed, so the later\nnfc_llcp_sock_unlink() in llcp_sock_release() becomes a no-op and no\ndouble put occurs.","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":"nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()","id":"CVE-2026-98581","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"race_condition","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"nfc: st21nfca: validate received frame size","id":"CVE-2026-98582"},"packages":[],"prev":{"headline":"nfc: llcp: Fix race condition in accept_queue lifecycle","id":"CVE-2026-98580"},"products":["Linux"],"published":"2026-10-18","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A race condition in the Linux kernel NFC LLCP handler allows local attackers to cause memory exhaustion and denial of service via list corruption.","url":"https://insights.sbomify.com/CVE-2026-98581/"}