smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs
Affects the Linux kernel SMB client's handling of compound encrypted frames in several stable branches, fixed in 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. CVSS rates it 8.8 (high).
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 6.1.189, 6.6.158, 6.12.112, 6.18.54, 7.2.8
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs Fix several related bounds checking and pointer lifecycle issues in receive_encrypted_standard()'s handling of compound encrypted frames: • Clear next_buffer after assigning it to server->bigbuf. A stale next_buffer pointer can lead to a use-after-free on subsequent error paths. • Update pdu_length to the decrypted plaintext size (buf_size). Using the pre-decryption length allows NextCommand to point into stale ciphertext residue. • Reject next_cmd values smaller than MID_HEADER_SIZE(server). • Fix an integer overflow in the upper bound check by verifying pdu_length - next_cmd < MID_HEADER_SIZE(server), ensuring the trailing slice is large enough for a header.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
4.19
- KernelLinux
From 4.19.0 · fixed in 6.1.189; From 6.2.0 · fixed in 6.6.158; From 6.7.0 · fixed in 6.12.112; From 6.13.0 · fixed in 6.18.54; From 6.19.0 · fixed in 7.2.8
References 8
git.kernel.org
- stable/c/1ed29f7a03417b405f38c09cfe04124883127b53
- stable/c/7f022867ec9f0166a0b4400385bb601b1c6b2c75
- stable/c/72eaef1f37a3b6bec11c342736834dc3707be3e4
- stable/c/491e33144dee872cffda207f6fcb09260728f803
- stable/c/8749946579708ea0d339034bb7f423a67dbe89cf
- stable/c/96c436e4b010711452b2872558938f4ef276492a
- stable/c/858d5ac22cb889266993e7670f9f0c4f4aeedd78
- stable/c/05762c5bc1cfdcac36747994fde2c04387a457f1
Questions about CVE-2026-98171
What does this mean?
A stale next_buffer pointer can lead to a use-after-free on later error paths. NextCommand can also point into stale ciphertext residue, because of missing bounds checks in compound PDU handling.Source: git.kernel.org
Am I affected, and how do I check?
The bug is in the SMB client's receive_encrypted_standard() path for compound encrypted frames. Kernel branches from 4.19.0 up to their fixed releases are in scope: before 6.1.189, before 6.6.158, before 6.12.112, before 6.18.54, and before 7.2.8. Check your version with uname -r.Source: git.kernel.org
What should I do about it?
Update the kernel to the fixed release for your branch: 6.1.189, 6.6.158, 6.12.112, 6.18.54, or 7.2.8 or later.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data