CVE-2026-98581 Affecting linux-6.12 package, versions <6.12.113-1~deb12u1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-DEBIAN12-LINUX612-21434688
- published23 Oct 2026
- disclosed18 Oct 2026
Introduced: 18 Oct 2026
NewCVE-2026-98581 (opens in a new tab)How to fix?
Upgrade Debian:12 linux-6.12 to version 6.12.113-1~deb12u1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream linux-6.12 package and not the linux-6.12 package as distributed by Debian.
See How to fix? for Debian:12 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()
nfc_llcp_recv_dm() handles DM(NOBOUND)/DM(REJ) for a socket that is still linked on local->connecting_sockets: it looks the socket up with nfc_llcp_connecting_sock_get(), sets sk->sk_state = LLCP_CLOSED and returns, without taking the socket lock and without unlinking the socket from the connecting_sockets list.
llcp_sock_release() selects the list to unlink from by sk_state: a socket in LLCP_CONNECTING is unlinked from connecting_sockets, otherwise from the sockets list. Because recv_dm left the socket physically on connecting_sockets but in the LLCP_CLOSED state, release() takes the else branch and calls nfc_llcp_sock_unlink(&local->sockets, sk). That runs sk_del_node_init() while holding sockets.lock, i.e. it removes the socket from the connecting_sockets hlist under the wrong lock. A concurrent connect() linking another socket onto connecting_sockets under connecting_sockets.lock then mutates the same hlist unserialized, which corrupts the list and desyncs the sk_add_node()/sk_del_node_init() sock_hold()/__sock_put() pairing. An unprivileged local process holding LLCP sockets, with the DM supplied by the remote peer over an established LLCP link, can drive this to leak kernel sockets without bound (the mis-decrement goes through the non-freeing __sock_put() path, so the object is never released), leading to memory exhaustion / DoS.
This is the same class of bug that was fixed in the sibling handler nfc_llcp_recv_cc() by commit b493ea2765cc ("nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()"); recv_dm did not receive the equivalent fix.
Fix it the same way: take lock_sock(), re-check that the socket is still hashed (release() may have won the race), and for the NOBOUND/REJ case unlink it from connecting_sockets before moving it to LLCP_CLOSED. The unlink drops the connecting_sockets membership reference via sk_del_node_init(), leaving the socket unhashed, so the later nfc_llcp_sock_unlink() in llcp_sock_release() becomes a no-op and no double put occurs.
References
- https://security-tracker.debian.org/tracker/CVE-2026-98581
- https://git.kernel.org/stable/c/320a2ff49bdce3f9a437b9a9ff341ff27d3bdbf1
- https://git.kernel.org/stable/c/7fb2c0eeb79bfad64065f539a453138abd0edda6
- https://git.kernel.org/stable/c/812731dd8511f5768f4ff279b3c18d85cd21da4b
- https://git.kernel.org/stable/c/b94cf09720543cc34256c7aa88f8059cbe7c0419
- https://git.kernel.org/stable/c/bf1460acdf8cf5a07c819f59785d40f20d113099
- https://git.kernel.org/stable/c/c1e9ed52a6697354366dddf190fbacee8ed2f7c5
- https://git.kernel.org/stable/c/dba1d9c7134afcb4b1bfad8c1b1b3f0ab5189b08
- https://git.kernel.org/stable/c/dd2d24add86b3b63cd87cf2feff98ae119ba19a6