CVE-2025-39975

What it actually does

Incorrect indexing in smb2_compound_op() when processing compound SMB2 response buffers causes out-of-bounds memory accesses when the computed index meets or exceeds MAX_COMPOUND.

Why it matters to the business

Linux systems acting as SMB clients may experience kernel crashes, memory corruption, or local privilege escalation, affecting file sharing and increasing risk on servers and containers that mount remote shares.

How an attack unfolds

An attacker controlling an SMB server or performing a man-in-the-middle attack returns a compound response with carefully chosen indices; the client loop then dereferences or writes beyond intended buffers, potentially leading to arbitrary kernel memory access.

How to fix it

Upgrade the Linux kernel to 6.6.109 or later (commit ba7bcfd52c66dd1c2dfa5142aca7e4a70b62dfa5) and apply the libvirt fixes 1.2.18.4-22.3.1 on affected SUSE products; rebuild and reboot systems that use the SMB client code path.

How to confirm the fix worked

Verify the running kernel contains commit ba7bcfd52c66dd1c2dfa5142aca7e4a70b62dfa5 or is version 6.6.109 or newer; confirm libvirt packages match the listed fixed versions on SUSE systems; review dmesg or kernel logs for prior oops related to smb2_compound_op.

Typical attack path

1. Attacker positions themselves as an SMB server or intercepts traffic to a legitimate server
2. Client initiates a compound SMB2 operation (multiple commands in one request)
3. Server returns responses with malformed or crafted index values in the response buffers
4. smb2_compound_op() loop uses the wrong indices, triggering out-of-bounds read or write
5. Resulting memory corruption is leveraged for denial of service or privilege escalation

How to detect it

Search kernel logs and audit trails for oops or panic messages referencing smb2_compound_op or compound response indexing; inspect SMB traffic captures for unusual compound response lengths or index values; correlate with process crashes in SMB-using workloads.

What your security team should do

• Prioritize patching kernel packages on all systems that mount SMB shares, especially those listed in CISA KEV-adjacent campaigns
• Apply the exact fixed versions provided for each distribution and rebuild initramfs if required
• Restrict SMB client usage to trusted servers until patches are deployed
• Monitor EPSS and threat actor activity for similar kernel compound-operation flaws