FKIE_CVE-2026-31613
Vulnerability from fkie_nvd - Published: 2026-04-24 15:16 - Updated: 2026-04-24 17:51
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOB reads parsing symlink error response
When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()
returns success without any length validation, leaving the symlink
parsers as the only defense against an untrusted server.
symlink_data() walks SMB 3.1.1 error contexts with the loop test "p <
end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset
0. When the server-controlled ErrorDataLength advances p to within 1-7
bytes of end, the next iteration will read past it. When the matching
context is found, sym->SymLinkErrorTag is read at offset 4 from
p->ErrorContextData with no check that the symlink header itself fits.
smb2_parse_symlink_response() then bounds-checks the substitute name
using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from
iov_base. That value is computed as sizeof(smb2_err_rsp) +
sizeof(smb2_symlink_err_rsp), which is correct only when
ErrorContextCount == 0.
With at least one error context the symlink data sits 8 bytes deeper,
and each skipped non-matching context shifts it further by 8 +
ALIGN(ErrorDataLength, 8). The check is too short, allowing the
substitute name read to run past iov_len. The out-of-bound heap bytes
are UTF-16-decoded into the symlink target and returned to userspace via
readlink(2).
Fix this all up by making the loops test require the full context header
to fit, rejecting sym if its header runs past end, and bound the
substitute name against the actual position of sym->PathBuffer rather
than a fixed offset.
Because sub_offs and sub_len are 16bits, the pointer math will not
overflow here with the new greater-than.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix OOB reads parsing symlink error response\n\nWhen a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()\nreturns success without any length validation, leaving the symlink\nparsers as the only defense against an untrusted server.\n\nsymlink_data() walks SMB 3.1.1 error contexts with the loop test \"p \u003c\nend\", but reads p-\u003eErrorId at offset 4 and p-\u003eErrorDataLength at offset\n0. When the server-controlled ErrorDataLength advances p to within 1-7\nbytes of end, the next iteration will read past it. When the matching\ncontext is found, sym-\u003eSymLinkErrorTag is read at offset 4 from\np-\u003eErrorContextData with no check that the symlink header itself fits.\n\nsmb2_parse_symlink_response() then bounds-checks the substitute name\nusing SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from\niov_base. That value is computed as sizeof(smb2_err_rsp) +\nsizeof(smb2_symlink_err_rsp), which is correct only when\nErrorContextCount == 0.\n\nWith at least one error context the symlink data sits 8 bytes deeper,\nand each skipped non-matching context shifts it further by 8 +\nALIGN(ErrorDataLength, 8). The check is too short, allowing the\nsubstitute name read to run past iov_len. The out-of-bound heap bytes\nare UTF-16-decoded into the symlink target and returned to userspace via\nreadlink(2).\n\nFix this all up by making the loops test require the full context header\nto fit, rejecting sym if its header runs past end, and bound the\nsubstitute name against the actual position of sym-\u003ePathBuffer rather\nthan a fixed offset.\n\nBecause sub_offs and sub_len are 16bits, the pointer math will not\noverflow here with the new greater-than."
}
],
"id": "CVE-2026-31613",
"lastModified": "2026-04-24T17:51:40.810",
"metrics": {},
"published": "2026-04-24T15:16:40.560",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/781902e069f4ecb6c3b83502f181972c1446110a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a66ef2e7ed837325c5600f8617d5ee0a0a149fdd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e0dd90d14cbbf318157ea8e3fb62ee68a28655ed"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
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…
Loading…