GHSA-H227-88M5-F744

Vulnerability from github – Published: 2026-10-18 18:31 – Updated: 2026-10-18 18:31
VLAI
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-98581"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-18T16:17:10Z",
    "severity": null
  },
  "details": "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.",
  "id": "GHSA-h227-88m5-f744",
  "modified": "2026-10-18T18:31:55Z",
  "published": "2026-10-18T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98581"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/320a2ff49bdce3f9a437b9a9ff341ff27d3bdbf1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7fb2c0eeb79bfad64065f539a453138abd0edda6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/812731dd8511f5768f4ff279b3c18d85cd21da4b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b94cf09720543cc34256c7aa88f8059cbe7c0419"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bf1460acdf8cf5a07c819f59785d40f20d113099"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c1e9ed52a6697354366dddf190fbacee8ed2f7c5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dba1d9c7134afcb4b1bfad8c1b1b3f0ab5189b08"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dd2d24add86b3b63cd87cf2feff98ae119ba19a6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.