{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98580 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98580 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-98580 and fix it if it is affected.\n\nWhat it is: CVE-2026-98580 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-98580 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-98580/ (Markdown: https://insights.sbomify.com/CVE-2026-98580/index.md)","id":"CVE-2026-98580","markdown":"https://insights.sbomify.com/CVE-2026-98580/index.md","name":"CVE-2026-98580","record":{"aliases":["AZL-109194","BELL-CVE-2026-98580","DEBIAN-CVE-2026-98580","GHSA-f48w-jg7j-gjm2","UBUNTU-CVE-2026-98580"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service","code_execution"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel NFC","requires_auth":"none","summary":"A race condition in the Linux kernel NFC LLCP subsystem allows concurrent socket release, leading to use-after-free or NULL dereference, potentially causing crashes or code execution.","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 race condition in accept_queue lifecycle\n\nIn nfc_llcp_socket_release(), sockets and listener accept queues are\nwalked under the local sockets rwlock and bh_lock_sock().  However,\nbh_lock_sock() does not synchronise against process-context lock_sock()\nheld by nfc_llcp_accept_dequeue() during accept().  Because\nsocket_release() does not check sock_owned_by_user(), both paths can\nconcurrently unlink and release the same child socket, resulting in\nuse-after-free or a NULL pointer dereference of child-\u003eparent in\nnfc_llcp_accept_unlink().\n\nFix this synchronisation race by having nfc_llcp_socket_release() use\nprocess-context lock_sock() instead of bh_lock_sock():\n\n1. Pop sockets from the local sockets list under the write lock using\n   nfc_llcp_sock_list_pop() so lock_sock() can be acquired without\n   holding the rwlock.\n\n2. Because lock_sock() can sleep, defer the final release of the\n   nfc_llcp_local structure to a workqueue (release_work).  This avoids\n   a sleeping-in-atomic bug when the last local reference is dropped\n   from softirq context.  Additionally, hold a single device reference\n   on local from registration until final destruction.\n\n3. In nfc_llcp_local_get(), use kref_get_unless_zero() to prevent\n   resurrecting a local object whose teardown has been scheduled.\n\n4. In llcp_sock_accept(), verify that the listener socket state is still\n   LLCP_LISTEN after waking from schedule_timeout() to prevent hangs if\n   the listener is closed concurrently.\n\n5. When unlinking unaccepted child sockets during listener release,\n   unlink them from local-\u003esockets, call sock_orphan(), and drop their\n   initial sk_alloc creation reference via sock_put().\n\n6. Make nfc_llcp_accept_unlink() idempotent by guarding parent access with\n   a NULL check.","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 race condition in accept_queue lifecycle","id":"CVE-2026-98580","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: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()","id":"CVE-2026-98581"},"packages":[],"prev":{"headline":"nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure","id":"CVE-2026-98579"},"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 subsystem allows concurrent socket release, leading to use-after-free or NULL dereference, potentially causing crashes or code execution.","url":"https://insights.sbomify.com/CVE-2026-98580/"}