CVE-2026-52941: Linux Kernel SMC-D DoS Vulnerability

CVE-2026-52941 Overview

CVE-2026-52941 is a NULL pointer dereference vulnerability in the Linux kernel's Shared Memory Communications (SMC) subsystem. The flaw resides in the smc_msg_event tracepoint class, which is shared by smc_tx_sendmsg and smc_rx_recvmsg. The tracepoint unconditionally dereferences smc->conn.lnk, but this pointer is only set for SMC-R connections and is NULL for SMC-D. When the tracepoint is enabled, the first sendmsg() or recvmsg() call on an SMC-D socket triggers a general protection fault, crashing the kernel.

Critical Impact
Local unprivileged users can trigger a kernel crash when the affected tracepoint is enabled, resulting in denial of service on systems supporting SMC-D, including s390 systems and x86 hosts with the loopback ISM device loaded.

Affected Products

Linux kernel versions containing the smc_msg_event tracepoint with unconditional conn->lnk dereference
Systems running SMC-D capable kernels on IBM s390 architecture
x86 Linux systems with the loopback ISM device loaded

Discovery Timeline

2026-06-24 - CVE-2026-52941 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52941

Vulnerability Analysis

The vulnerability is a NULL pointer dereference [CWE-476] in the Linux kernel's net/smc subsystem. The smc_msg_event tracepoint class stores an ibname string using the macro __string(name, smc->conn.lnk->ibname). This unconditionally dereferences conn->lnk without checking whether the link pointer is set.

SMC supports two operating modes. SMC-R uses RDMA over Converged Ethernet and populates conn->lnk with a valid smc_link structure. SMC-D uses shared memory via ISM devices and leaves conn->lnk as NULL. Other code paths in the SMC subsystem already account for this distinction, for example the !conn->lnk guard in SMC_STAT_RMB_TX_SIZE_SMALL().

When the tracepoint is enabled and an SMC-D socket performs the first sendmsg() or recvmsg(), the tracepoint handler calls strlen() on a NULL-derived pointer. The faulting address is 0x3e0, which corresponds to offsetof(struct smc_link, ibname), confirming the NULL ->lnk deref.

Root Cause

The root cause is missing input validation in tracepoint instrumentation. The tracepoint author assumed conn->lnk was always valid because most SMC code paths execute in SMC-R context. Tracepoints execute inline within hot paths and must validate pointers before dereference, particularly for unions or optional structure members.

Attack Vector

Enabling the tracepoint requires root privileges through tracefs or eBPF tracing facilities. However, the trigger itself is unprivileged. The socket(AF_SMC, ...) call performs no capability check, and SMC-D negotiation requires no administrative action on s390 systems or on x86 with the loopback ISM device loaded. An unprivileged local process can crash the kernel by issuing a single recvmsg() or sendmsg() on an SMC-D socket once an administrator or monitoring agent has enabled SMC tracing.

The vulnerability manifests in the trace_event_raw_event_smc_msg_event handler. See the upstream commits referenced below for technical details on the fix, which logs an empty device name for SMC-D instead of dereferencing NULL.

Detection Methods for CVE-2026-52941

Indicators of Compromise

Kernel oops messages containing general protection fault with RIP: strlen+0x1e/0xa0 in the call trace
KASAN reports of null-ptr-deref referencing offset 0x3e0 within the SMC code path
Call traces including trace_event_raw_event_smc_msg_event, smc_rx_recvmsg, or smc_tx_sendmsg
Unexpected kernel panics on s390 hosts or x86 systems with the loopback ISM module loaded

Detection Strategies

Audit kernel dmesg and persistent crash logs for SMC-related general protection faults
Inspect tracefs state at /sys/kernel/tracing/events/smc/ to identify hosts where smc_msg_event tracing has been enabled
Inventory kernel versions across the fleet and cross-reference against the fix commits 561cf66f, 68200112, 720c76b9, 7bf563ba, b706d6d7, and d2ea0b8a

Monitoring Recommendations

Forward kernel logs to a centralized logging platform and alert on smc_ symbols appearing in oops traces
Monitor for lsmod output showing smc, smc_diag, or ISM device modules on systems that do not require SMC functionality
Track tracepoint enable events through audit rules on /sys/kernel/tracing/ writes

How to Mitigate CVE-2026-52941

Immediate Actions Required

Apply the upstream kernel patches referenced in the stable tree commits as soon as vendor-supplied updates become available
Disable the smc_msg_event tracepoint on production hosts until patches are deployed
Blocklist the smc and ism kernel modules on systems that do not require Shared Memory Communications
Restrict access to tracefs and eBPF tracing facilities to a minimal set of administrators

Patch Information

The fix logs an empty device name for SMC-D connections instead of dereferencing the NULL conn->lnk pointer. The patch is available across multiple stable branches via the following commits: Linux Kernel Commit 561cf66, Linux Kernel Commit 68200112, Linux Kernel Commit 720c76b9, Linux Kernel Commit 7bf563ba, Linux Kernel Commit b706d6d7, and Linux Kernel Commit d2ea0b8a.

Workarounds

Leave the smc_msg_event tracepoint disabled in production environments
Unload the loopback ISM device module on x86 systems where SMC-D is not required
Add smc to the kernel module blocklist using /etc/modprobe.d/ to prevent the AF_SMC socket family from being available

bash

# Configuration example
# Disable the affected tracepoint at runtime
echo 0 > /sys/kernel/tracing/events/smc/smc_tx_sendmsg/enable
echo 0 > /sys/kernel/tracing/events/smc/smc_rx_recvmsg/enable

# Prevent SMC modules from loading
cat <<EOF > /etc/modprobe.d/blacklist-smc.conf
blacklist smc
blacklist smc_diag
blacklist ism
EOF