GHSA-5C3G-3V2R-672G

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix null pointer dereference in compare_guid_key()

session_fd_check() walks the per-inode m_op_list during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid lease_table_list entry's lb->lease_list because destroy_lease_table() only runs on full TCP-connection teardown, not on SESSION_LOGOFF.

If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, find_same_lease_key() walks lb->lease_list, reaches the stale opinfo, and calls compare_guid_key(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics.

Reproducer requires only a successful SMB2 SESSION_SETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:

general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handle_ksmbd_work RIP: 0010:bcmp+0x5b/0x230 Call Trace: compare_guid_key+0x4b/0xd0 find_same_lease_key+0x324/0x690 smb2_open+0x6aea/0x8e60 handle_ksmbd_work+0x796/0xee0 ...

Faulting address 0x348 is the offset of ClientGUID within struct ksmbd_conn, confirming opinfo->conn was NULL.

Read opinfo->conn once and bail out if it has been cleared by a concurrent session_fd_check(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64141"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:55Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix null pointer dereference in compare_guid_key()\n\nsession_fd_check() walks the per-inode m_op_list during durable-handle\nsession teardown and sets op-\u003econn = NULL for every opinfo whose conn\nmatched the closing session\u0027s connection. The matching opinfo, however,\nstays linked in its per-ClientGuid lease_table_list entry\u0027s lb-\u003elease_list\nbecause destroy_lease_table() only runs on full TCP-connection teardown,\nnot on SESSION_LOGOFF.\n\nIf the same TCP connection then negotiates a fresh session with the\nsame ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and\nis unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a\nlease context on a different inode, find_same_lease_key() walks\nlb-\u003elease_list, reaches the stale opinfo, and calls compare_guid_key(),\nwhich unconditionally dereferences opinfo-\u003econn-\u003eClientGUID. The conn\npointer is NULL and the kernel panics.\n\nReproducer requires only a successful SMB2 SESSION_SETUP and a share\nconfigured with \u0027durable handles = yes\u0027. KASAN report on mainline\n70390501d194:\n\n  general protection fault, probably for non-canonical address\n  0xdffffc0000000069: 0000 [#1] SMP KASAN PTI\n  KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f]\n  Workqueue: ksmbd-io handle_ksmbd_work\n  RIP: 0010:bcmp+0x5b/0x230\n  Call Trace:\n   compare_guid_key+0x4b/0xd0\n   find_same_lease_key+0x324/0x690\n   smb2_open+0x6aea/0x8e60\n   handle_ksmbd_work+0x796/0xee0\n   ...\n\nFaulting address 0x348 is the offset of ClientGUID within struct\nksmbd_conn, confirming opinfo-\u003econn was NULL.\n\nRead opinfo-\u003econn once and bail out if it has been cleared by a\nconcurrent session_fd_check(). A half-detached opinfo cannot be the\nowner of an active lease, so returning 0 is the correct match result.",
  "id": "GHSA-5c3g-3v2r-672g",
  "modified": "2026-07-20T15:32:01Z",
  "published": "2026-07-19T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64141"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0836081b394ca074d1b910f2b990ff7b4b4404c7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b83cbc4c15f09b000cc06f033f64b0824b6dc87"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/af86896ca3239e25a6bd7d352213371265073d38"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cd5c1b75d2f454f625d7dc55bd3ae21d0855f6ad"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e43cb36d4d7827710cfcd48e95e29a507f0d87be"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…