CVE-2026-52967

What it actually does

This vulnerability affects the Linux kernel SMB/CIFS client code path that parses symlink error-context data returned by an SMB server. On 32-bit architectures, a malicious or malformed server response can cause integer/pointer wraparound in symlink_data(), resulting in either an infinite parsing loop or an out-of-bounds read. The most likely technical outcome is kernel-level denial of service through a hung task, soft lockup, or kernel fault when a vulnerable client follows or processes a crafted SMB symlink response. Exploitation requires the vulnerable system to act as an SMB client and interact with a malicious, compromised, or man-in-the-middle-controlled SMB server/share.

Why it matters to the business

Systems that mount SMB/CIFS shares from untrusted or compromised servers could become unstable or unavailable, especially 32-bit Linux deployments. The operational impact is primarily service disruption: affected hosts may hang, require reboot, lose access to mounted network shares, or experience application downtime if business processes depend on SMB-mounted storage. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so broad opportunistic exploitation appears less likely; however, exposure is still meaningful where clients connect to third-party, user-controlled, or less-trusted SMB servers.

How an attack unfolds

An attacker first needs to place themselves in control of an SMB server that a vulnerable Linux client will access, compromise an existing SMB server, or intercept/modify SMB traffic in a position where SMB responses can be manipulated. The attacker then causes the client to access a crafted symlink or SMB object that triggers the vulnerable symlink_data() parsing logic. The malicious response uses specially chosen ErrorDataLength values that, on 32-bit systems, cause pointer arithmetic to wrap. Depending on the crafted length, the kernel SMB client may repeatedly process the same structure without making progress, causing an infinite loop, or read memory outside the expected buffer. The end result is typically a kernel hang, soft lockup, crash, or forced reboot rather than data theft or remote code execution based on the provided information.

How to fix it

Apply the vendor-provided Linux kernel update that includes the smb/client symlink_data() fix. Because no exact affected product list or fixed package versions were provided, use the security advisory from the relevant Linux distribution, appliance vendor, or kernel provider to identify the corrected kernel build. Prioritize 32-bit Linux systems and any systems that mount SMB/CIFS shares from untrusted, user-controlled, partner-managed, internet-adjacent, or less tightly governed servers. If immediate patching is not possible, reduce risk by disabling unnecessary SMB/CIFS mounts, avoiding untrusted SMB servers, restricting outbound SMB access to approved servers, enforcing network segmentation, and using firewall controls to block SMB traffic except where explicitly required. Consider remounting only after patching where the SMB server cannot be fully trusted.

How to confirm the fix worked

Confirm that affected systems are running a kernel package containing the upstream smb/client symlink_data() fix or the distribution backport for this CVE. Validate by checking the installed kernel version against the vendor advisory rather than relying only on upstream version numbers, because many distributions backport security patches. Inventory systems using CIFS/SMB mounts by reviewing mounted filesystems, /etc/fstab entries, systemd mount units, and use of mount.cifs. Give special attention to 32-bit architectures. After remediation, reboot into the patched kernel where required and confirm that the active kernel is the patched one. Review kernel logs after SMB access tests for absence of CIFS-related soft lockups, hung tasks, kernel oops messages, or symlink_data-related faults.

Typical attack path

1. Identify or entice a vulnerable 32-bit Linux system that mounts SMB/CIFS shares.
2. Gain control of an SMB server the target client accesses, or position on-path to tamper with SMB responses.
3. Serve a crafted SMB response involving symlink error-context data with malicious ErrorDataLength values.
4. Trigger the client to access the crafted symlink or path on the SMB share.
5. Cause the Linux kernel SMB client to enter an infinite loop or perform an out-of-bounds read.
6. Disrupt the affected host, SMB-dependent workloads, or services relying on the mounted share.

How to detect it

To determine whether exploitation may have already occurred, review kernel and system logs on Linux clients that mount SMB/CIFS shares. Focus on time windows around SMB share access, automount activity, file browsing, backup jobs, or application activity involving network-mounted paths. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dump metadata, and EDR telemetry for mount.cifs or kernel fault events. Look for CIFS/SMB client messages immediately followed by soft lockups, hung task reports, kernel oops/panic messages, paging faults, or watchdog resets. Network telemetry can help identify suspicious or unexpected SMB servers contacted before a crash or hang, especially outbound TCP/445 connections to unapproved destinations. Because this flaw primarily causes denial of service and no stable attacker payload indicators are provided, detection should emphasize behavioral correlation: SMB client activity followed by kernel instability on 32-bit systems. If available, inspect packet captures for malformed SMB symlink or error-context responses from the server side, but absence of a capture does not rule out exploitation.

• symlink_data
• CIFS: VFS
• mount.cifs
• cifs.ko
• BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• INFO: task
• blocked for more than
• kernel panic
• Oops:
• unable to handle kernel paging request
• general protection fault
• TCP/445
• TCP/139

What your security team should do

• Identify Linux systems using SMB/CIFS client mounts, especially 32-bit systems and hosts connecting to non-internal or less-trusted SMB servers.
• Patch affected systems using the appropriate vendor kernel update and reboot where necessary to load the corrected kernel.
• Restrict SMB/CIFS client access so systems can connect only to approved SMB servers; block unnecessary outbound TCP/445 and TCP/139 traffic.
• Review SMB-mounted workloads for business criticality and prioritize systems where an outage would affect production services, backups, file processing, or user access.
• Monitor kernel logs for CIFS/SMB client crashes, soft lockups, hung tasks, and symlink_data-related errors after SMB share access.
• If suspicious crashes correlate with SMB access, preserve kernel logs, mount history, network flow records, and packet captures if available.
• For untrusted SMB workflows, consider isolating access through hardened intermediary systems until all clients are patched.