GHSA-WWVC-XJ6P-8PQH
Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-15 06:32In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix stack buffer overflow in multichannel session-key copy
Commit 4b706360ffb7 ("ksmbd: fix multichannel binding and enforce channel limit") moved the binding-path session key out of the session-wide sess->sess_key (CIFS_KEY_SIZE = 40) into a new per-channel buffer, and sized both that buffer and the on-stack copy used during binding with SMB2_NTLMV2_SESSKEY_SIZE (16):
struct channel {
char sess_key[SMB2_NTLMV2_SESSKEY_SIZE]; /* 16 */
...
};
ntlm_authenticate() / krb5_authenticate():
char channel_key[SMB2_NTLMV2_SESSKEY_SIZE] = {}; /* 16 */
char *auth_key = conn->binding ? channel_key : sess->sess_key;
The two writers that fill this destination still bound the copy length against CIFS_KEY_SIZE (40), not against the 16-byte buffer:
ksmbd_decode_ntlmssp_auth_blob() (NTLM key exchange):
if (sess_key_len > CIFS_KEY_SIZE) /* 40 */
return -EINVAL;
arc4_crypt(ctx_arc4, sess_key,
(char *)authblob + sess_key_off, sess_key_len);
ksmbd_krb5_authenticate():
if (resp->session_key_len > sizeof(sess->sess_key)) /* 40 */
...
memcpy(sess_key, resp->payload, resp->session_key_len);
On a binding SESSION_SETUP, auth_key points at the 16-byte channel_key, so a client that supplies an NTLM EncryptedRandomSessionKey of up to 40 bytes (with NTLMSSP_NEGOTIATE_KEY_EXCH), or a Kerberos ticket whose session key is longer than 16 bytes (a normal AES256 key is 32), writes past the 16-byte stack buffer -- up to a 24-byte kernel stack overflow. KASAN reports it as a stack-out-of-bounds write in arc4_crypt() called from ksmbd_decode_ntlmssp_auth_blob().
The destinations must be able to hold the full session key the length checks already permit. Size the per-channel key buffer and the two on-stack channel_key buffers with CIFS_KEY_SIZE, matching sess->sess_key.
{
"affected": [],
"aliases": [
"CVE-2026-72044"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T06:21:13Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix stack buffer overflow in multichannel session-key copy\n\nCommit 4b706360ffb7 (\"ksmbd: fix multichannel binding and enforce channel\nlimit\") moved the binding-path session key out of the session-wide\nsess-\u003esess_key (CIFS_KEY_SIZE = 40) into a new per-channel buffer, and\nsized both that buffer and the on-stack copy used during binding with\nSMB2_NTLMV2_SESSKEY_SIZE (16):\n\n\tstruct channel {\n\t\tchar\tsess_key[SMB2_NTLMV2_SESSKEY_SIZE];\t/* 16 */\n\t\t...\n\t};\n\n\tntlm_authenticate() / krb5_authenticate():\n\t\tchar channel_key[SMB2_NTLMV2_SESSKEY_SIZE] = {};\t/* 16 */\n\t\tchar *auth_key = conn-\u003ebinding ? channel_key : sess-\u003esess_key;\n\nThe two writers that fill this destination still bound the copy length\nagainst CIFS_KEY_SIZE (40), not against the 16-byte buffer:\n\n\tksmbd_decode_ntlmssp_auth_blob() (NTLM key exchange):\n\t\tif (sess_key_len \u003e CIFS_KEY_SIZE)\t/* 40 */\n\t\t\treturn -EINVAL;\n\t\tarc4_crypt(ctx_arc4, sess_key,\n\t\t\t (char *)authblob + sess_key_off, sess_key_len);\n\n\tksmbd_krb5_authenticate():\n\t\tif (resp-\u003esession_key_len \u003e sizeof(sess-\u003esess_key))\t/* 40 */\n\t\t\t...\n\t\tmemcpy(sess_key, resp-\u003epayload, resp-\u003esession_key_len);\n\nOn a binding SESSION_SETUP, auth_key points at the 16-byte channel_key,\nso a client that supplies an NTLM EncryptedRandomSessionKey of up to 40\nbytes (with NTLMSSP_NEGOTIATE_KEY_EXCH), or a Kerberos ticket whose\nsession key is longer than 16 bytes (a normal AES256 key is 32), writes\npast the 16-byte stack buffer -- up to a 24-byte kernel stack overflow.\nKASAN reports it as a stack-out-of-bounds write in arc4_crypt() called\nfrom ksmbd_decode_ntlmssp_auth_blob().\n\nThe destinations must be able to hold the full session key the length\nchecks already permit. Size the per-channel key buffer and the two\non-stack channel_key buffers with CIFS_KEY_SIZE, matching sess-\u003esess_key.",
"id": "GHSA-wwvc-xj6p-8pqh",
"modified": "2026-08-15T06:32:10Z",
"published": "2026-08-15T06:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72044"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/610346149d047a52a92c9a0eb329dd565b8f92c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a7f7b55d7d0fbc4662c981ee6c56e081fa66d58"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
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
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.