ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: if (conn->use_spnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL; } so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.212, 6.1.178, 6.12.83, 6.18.24, 6.19.14, 6.6.136, 7.0.1
- CVEs
- CVE-2026-31610
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 7 Nov 2026, 03:35 UTC · Revision 1
Source evidence
ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc
core-osv · Original sourcePublished 24 Apr 2026, 14:42 UTC
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: if (conn->use_spnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL; } so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.
osv:CVE-2026-31610
Kernel
Fixed versions: 5.15.212, 6.1.178, 6.6.136, 6.12.83, 6.18.24, 6.19.14, 7.0.1
Complete source record
{
"id": "e21c7f65d09ec639342074c467418197daf18bc4bb387dc05f84384c7b41f3f9",
"url": "https://osv.dev/vulnerability/CVE-2026-31610",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc",
"summary": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: if (conn->use_spnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL; } so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.",
"evidence": "osv:CVE-2026-31610",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.212",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.178",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.136",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.83",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.24",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.14",
"evidence": "/affected/1/ranges"
},
{
"value": "7.0.1",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-31610",
"aliases": [
"CVE-2026-31610"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "fad4161b5cd01a24202234976ebbb133f7adc0b5"
},
{
"fixed": "ae9cdb29efed20ffdee9ff3b0bb72fb369c353da"
},
{
"fixed": "bd4a7fb04f06f419b0e93d8b52fe32067eb312d1"
},
{
"fixed": "745a535461bbb90a56d9357573c9f97a5c12abe1"
},
{
"fixed": "dd577cb55588ec3fbc66af3621280306601c4192"
},
{
"fixed": "dd53414e301beb915fe672dc4c4a51bafb917604"
},
{
"fixed": "269c800a7a7e363459291885b35f7bc72e231ed6"
},
{
"fixed": "6c8c44e6553b9f072f62d9875e567766eb293162"
},
{
"fixed": "ad0057fb91218914d6c98268718ceb9d59b388e1"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31610.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.15.0"
},
{
"fixed": "5.15.212"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.178"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.136"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.83"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.24"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.14"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.20.0"
},
{
"fixed": "7.0.1"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31610.json"
}
}
],
"modified": "2026-10-28T02:30:49.600923652Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/269c800a7a7e363459291885b35f7bc72e231ed6",
"https://git.kernel.org/stable/c/6c8c44e6553b9f072f62d9875e567766eb293162",
"https://git.kernel.org/stable/c/745a535461bbb90a56d9357573c9f97a5c12abe1",
"https://git.kernel.org/stable/c/ad0057fb91218914d6c98268718ceb9d59b388e1",
"https://git.kernel.org/stable/c/ae9cdb29efed20ffdee9ff3b0bb72fb369c353da",
"https://git.kernel.org/stable/c/bd4a7fb04f06f419b0e93d8b52fe32067eb312d1",
"https://git.kernel.org/stable/c/dd53414e301beb915fe672dc4c4a51bafb917604",
"https://git.kernel.org/stable/c/dd577cb55588ec3fbc66af3621280306601c4192",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31610.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-31610",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31610.json"
}
},
"related_cves": [
{
"value": "CVE-2026-31610",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 517801,
"published_at": "2026-04-24T14:42:31.471+00:00"
}