CVE-2026-46185

What it actually does

This is an out-of-bounds read in the Linux kernel SMB client code path that processes SMB2 symlink error responses. The vulnerable logic can treat a malformed or truncated SMB2 error response as valid and then read fields such as ErrorContextCount or ByteCount beyond the received buffer. A malicious SMB server, compromised SMB server, or network-positioned attacker capable of influencing SMB traffic could potentially trigger kernel memory disclosure or crash the client system. The impact is primarily confidentiality and availability; there is no clear indication from the provided data that this enables arbitrary code execution.

Why it matters to the business

Systems that use the Linux kernel SMB/CIFS client to access SMB file shares may be exposed to crashes or possible kernel memory disclosure when interacting with a malicious or compromised SMB server. This can disrupt file access, interrupt dependent applications, and create operational instability for workloads relying on SMB-mounted storage. The CVSS score is high at 9.1, but EPSS is currently low at 0.00513, it is not listed in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized for systems that mount untrusted, internet-adjacent, partner-managed, or broadly accessible SMB shares.

How an attack unfolds

An attacker first needs a way to make a vulnerable Linux system process SMB2 responses from an attacker-controlled or attacker-influenced SMB endpoint. This could occur if a system mounts an SMB share from a malicious server, connects to a compromised file server, or communicates over a network path where SMB traffic can be manipulated. The attacker sends a specially crafted SMB2 symlink error response that is shorter than the structure the kernel SMB client expects, for example a response containing only the base SMB2 header. Because the validation path can incorrectly accept the message without confirming the full response length, the kernel later reads fields past the end of the received buffer in symlink_data(). Depending on memory layout and kernel hardening, the result may be a kernel fault, denial of service, or exposure of adjacent kernel memory contents through subsequent handling of the malformed response.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the fix for the SMB client symlink_data() out-of-bounds read. Because no specific fixed versions were provided, use distribution security advisories and package metadata for the exact corrected kernel package for each platform. After updating, reboot systems or otherwise ensure the patched kernel is the running kernel; updating the package alone is insufficient if the vulnerable kernel remains loaded. Where immediate patching is not possible, reduce exposure by avoiding SMB mounts from untrusted or unmanaged servers, restricting outbound SMB traffic to approved file servers, disabling unnecessary CIFS/SMB client usage, and using network controls to prevent SMB interception or redirection. Treat SMB servers that can influence Linux clients as part of the trusted computing base until affected clients are patched.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that includes the vendor fix, not merely that an updated package is installed. Validate with commands such as uname -r and distribution package tools, then compare against the relevant vendor advisory for the corrected kernel version. Inventory active SMB/CIFS mounts using mount, findmnt, /proc/mounts, or equivalent endpoint telemetry to determine whether systems actually exercise the vulnerable client path. Where safe testing is available, verify that malformed or truncated SMB2 symlink error responses are rejected without kernel warnings, KASAN reports, oopses, or client instability. Review kernel logs after patching and rebooting to ensure no recurring CIFS/SMB client faults are observed.

Typical attack path

1. Identify or lure a Linux system that uses the kernel SMB/CIFS client to connect to an SMB share.
2. Operate, compromise, or position in front of an SMB server that the vulnerable client will contact.
3. Return a malformed or truncated SMB2 symlink error response that passes initial message validation.
4. Trigger the vulnerable symlink_data() parsing path in the Linux kernel SMB client.
5. Cause an out-of-bounds kernel read, potentially resulting in a client crash or kernel memory disclosure.

How to detect it

Look for evidence that Linux systems using the SMB/CIFS client experienced kernel faults or abnormal CIFS behavior after communicating with SMB servers. Useful sources include kernel logs, system journals, crash dumps, endpoint telemetry, SMB client mount history, network flow logs for TCP/445 and TCP/139, and packet captures if available. Focus on systems with active CIFS mounts and investigate kernel oops, panic, KASAN, or slab out-of-bounds messages referencing symlink_data, smb2, cifs, or SMB2 error response handling. Correlate crash times with outbound SMB connections to newly introduced, external, unusual, or recently compromised SMB servers. Network evidence may include malformed SMB2 error responses with an SMB2 header but insufficient payload length for the error response structure. Because exploitation may present only as a kernel crash, absence of application-layer logs does not rule it out.

• BUG: KASAN: slab-out-of-bounds in symlink_data
• BUG: KASAN: out-of-bounds in symlink_data
• symlink_data
• smb2_check_message
• CIFS: VFS
• cifs.ko
• SMB2
• kernel BUG at fs/smb/client
• kernel BUG at fs/cifs
• general protection fault
• Unable to handle kernel paging request
• Oops:
• TCP/445
• TCP/139

What your security team should do

• Prioritize patching Linux systems that mount SMB/CIFS shares, especially servers, storage clients, backup infrastructure, build systems, and workloads that connect to third-party or less-trusted SMB servers.
• Use distribution advisories to identify the exact fixed kernel packages and ensure patched kernels are actively running after reboot.
• Inventory SMB/CIFS client usage across Linux fleets and restrict outbound TCP/445 and TCP/139 to approved SMB servers.
• Monitor for kernel oops, panic, KASAN, or CIFS-related errors on systems with SMB mounts, especially following access to symlinks or unusual SMB server responses.
• Review trust boundaries for SMB shares; avoid mounting SMB shares from untrusted networks and require secure network paths, segmentation, and server authentication where possible.
• If suspicious crashes occurred before patching, preserve kernel logs, crash dumps, SMB client configuration, mount history, and network telemetry for forensic review.