Description
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.
Published: 2026-10-18
Score: 4.7 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service via kernel memory exhaustion
Action: Apply Patch
AI Analysis

Impact

The Linux kernel's NFC Low‑Layer Communication protocol contains a missing lock and unlink sequence in the DM handling path. An unprivileged local process can send a malformed DM message over an existing LLCP link, causing the socket to remain on the connecting list while in a closed state. This race results in list corruption and a reference‑count desynchronization that leaks kernel socket objects. The outcome is a gradual depletion of available kernel memory, leading to a DoS attack. The flaw is a use‑after‑free and race‑condition weakness (CWE-413).

Affected Systems

Based on the description, it is inferred that all Linux kernel installations that have not incorporated the fix commit are affected. The advisory does not explicitly enumerate affected kernel versions; the vulnerability existed in mainline kernel generations serviced by the community and upstream vendors until the patch was applied.

Risk and Exploitability

The vulnerability requires local exploitation by a non‑privileged user with access to the NFC stack and a pre‑established LLCP link. The CVSS score of 4.7 indicates moderate severity. The EPSS score of <1% suggests a very low likelihood of exploitation, and KEV is not listed. Because it is a race condition, exploitation is not trivially deterministic; the risk is considered moderate to high for environments that rely on NFC functionality, with a potential for complete denial of kernel services once memory exhaustion occurs.

Generated by OpenCVE AI on October 22, 2026 at 21:55 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the kernel to a version that includes the patch corresponding to commit 320a2ff49bdce3f9a437b9a9ff341ff27d3bdbf1
  • If a kernel upgrade is not immediately possible, disable the NFC LLCP interface or block NFC traffic to prevent malicious DM messages from reaching the kernel until the fix is applied
  • Monitor system memory usage for unexpected depletion patterns that may indicate an ongoing race‑condition attack

Generated by OpenCVE AI on October 22, 2026 at 21:55 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4850-1 linux-6.12 security update
Ubuntu USN Ubuntu USN USN-8961-1 Linux kernel vulnerabilities
History

Tue, 20 Oct 2026 20:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-1343
CWE-416

Tue, 20 Oct 2026 12:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-413
References
Metrics threat_severity

None

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Sun, 18 Oct 2026 23:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-1343
CWE-416

Sun, 18 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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.
Title nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:22:07.016Z

Reserved: 2026-09-25T10:25:14.358Z

Link: CVE-2026-98581

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:10.610

Modified: 2026-10-19T10:19:18.807

Link: CVE-2026-98581

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-18T00:00:00Z

Links: CVE-2026-98581 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-22T22:00:15Z

Weaknesses
  • CWE-413

    Improper Resource Locking