CVE-2026-52941

What it actually does

This flaw is a Linux kernel NULL pointer dereference in the SMC networking subsystem tracepoint used by smc_tx_sendmsg and smc_rx_recvmsg. When the smc_msg_event tracepoint is enabled, the tracepoint assumes smc->conn.lnk is valid and dereferences smc->conn.lnk->ibname. That assumption is true for SMC-R but false for SMC-D, where conn.lnk is NULL. A sendmsg() or recvmsg() operation on an SMC-D socket can therefore trigger a kernel oops/general protection fault in strlen() via trace_event_raw_event_smc_msg_event, causing a local denial of service. Enabling the vulnerable tracepoint requires privileged access, but once enabled, the crash trigger can be exercised by an unprivileged local user if SMC-D is available, such as on s390 or x86 systems with a loopback ISM device loaded.

Why it matters to the business

The primary risk is unexpected system crash or instability on Linux hosts where SMC-D is available and the affected tracepoint is enabled. This can interrupt workloads, terminate active sessions, cause service downtime, and require host reboot or recovery. The vulnerability is not known to be exploited in the wild, is not in the CISA Known Exploited Vulnerabilities catalog, has low EPSS, and is not associated with ransomware activity, so broad emergency response is generally not indicated; however, production systems using kernel tracing, SMC, s390, or loopback ISM configurations should prioritize validation and patching because the trigger itself may be available to unprivileged local users once tracing is enabled.

How an attack unfolds

An attacker first needs a system state where the vulnerable SMC message tracepoint is enabled, which normally requires root or equivalent privileges through tracing facilities such as ftrace/tracefs/perf-style instrumentation. The attacker then opens an AF_SMC socket and negotiates or uses an SMC-D path, where the kernel connection structure has no SMC-R link pointer. When the attacker performs the first sendmsg() or recvmsg() operation on that SMC-D socket, the enabled tracepoint attempts to copy or format the device name by reading smc->conn.lnk->ibname. Because conn.lnk is NULL for SMC-D, the kernel dereferences a NULL-derived address and faults in strlen(), producing an oops or general protection fault. Depending on kernel panic settings and system configuration, this may crash the host immediately or leave it degraded after a kernel oops.

How to fix it

Apply a Linux kernel update that includes the fix for the SMC tracepoint NULL dereference. The corrected behavior logs an empty device name for SMC-D instead of dereferencing conn.lnk. No exact fixed package versions were provided in the input, so use the relevant vendor kernel advisory for each distribution or kernel stream and update to the first version containing the upstream fix for net/smc smc_msg_event handling. As interim mitigations, disable the affected SMC message tracepoints where operationally feasible, restrict access to tracing facilities such as tracefs/debugfs/perf to trusted administrators only, disable or unload SMC/SMC-D or loopback ISM support if not required, and consider hardening kernel panic/oops behavior according to availability requirements. Because the trigger can be unprivileged after the tracepoint is enabled, do not rely solely on user permissions around AF_SMC sockets if tracing remains enabled.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the vendor fix for the SMC tracepoint issue, not merely that an updated package is installed pending reboot. Check the active kernel with uname -r and compare it to the distribution advisory or fixed kernel package version. If safe in a non-production test environment, enable the relevant SMC message tracepoint and exercise SMC-D sendmsg()/recvmsg(); a fixed kernel should not crash and should emit an empty device name for SMC-D. Validate mitigations by checking that vulnerable tracepoints are disabled, tracefs/debugfs access is restricted to administrators, and unnecessary SMC-D or loopback ISM components are not loaded. Review kernel logs after validation to ensure there are no new general protection faults, NULL pointer dereferences, or smc_msg_event stack traces.

Typical attack path

1. Identify a Linux host running an affected kernel with AF_SMC/SMC-D support available.
2. Ensure or wait for the vulnerable smc_msg_event tracepoint to be enabled through privileged tracing configuration.
3. From a local user context, create an AF_SMC socket without requiring special capabilities.
4. Use an SMC-D communication path, such as native SMC-D on s390 or loopback ISM on x86 when available.
5. Call sendmsg() or recvmsg() on the SMC-D socket.
6. Trigger a NULL pointer dereference in the kernel tracepoint, resulting in a kernel oops, general protection fault, host instability, or denial of service.

How to detect it

To determine whether this vulnerability was already triggered, review kernel and system logs for crash signatures involving the SMC subsystem and the smc_msg_event tracepoint. Useful sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump metadata, kdump/vmcore records, kernel oops collectors, EDR kernel telemetry, and observability tooling that enables Linux tracepoints. Look for general protection faults, NULL pointer dereferences, KASAN null-ptr-deref messages, RIP entries in strlen(), and call traces containing trace_event_raw_event_smc_msg_event, smc_rx_recvmsg, smc_tx_sendmsg, smc_recvmsg, or AF_SMC activity. Also review tracefs state to determine whether SMC tracepoints were enabled around the time of the crash, especially under /sys/kernel/tracing/events/smc/ or /sys/kernel/debug/tracing/events/smc/. Because the trigger can be unprivileged but tracepoint enablement is privileged, correlate crash timing with administrator activity, tracing/diagnostic sessions, performance monitoring agents, changes to tracefs files, loading of ISM/SMC-related modules, and local process activity creating AF_SMC sockets. There are no known public threat actors, ransomware campaigns, or confirmed in-the-wild exploitation associated with this issue based on the supplied data.

• trace_event_raw_event_smc_msg_event
• smc_msg_event
• smc_rx_recvmsg
• smc_tx_sendmsg
• smc_recvmsg
• smc_recvmsg (net/smc/af_smc.c
• smc_rx_recvmsg (net/smc/smc_rx.c
• net/smc/smc_tracepoint.h:44
• RIP: 0010:strlen
• KASAN: null-ptr-deref
• Oops: general protection fault
• probably for non-canonical address
• faulting address 0x3e0
• socket(AF_SMC
• /sys/kernel/tracing/events/smc/
• /sys/kernel/debug/tracing/events/smc/
• /sys/kernel/tracing/events/smc/smc_msg_event/enable
• /sys/kernel/debug/tracing/events/smc/smc_msg_event/enable

What your security team should do

• Inventory Linux systems where AF_SMC, SMC-D, s390, or loopback ISM are enabled, especially hosts using kernel tracing or observability tooling.
• Prioritize kernel updates for systems that expose SMC-D functionality and have tracing enabled in production.
• Verify that tracing interfaces such as /sys/kernel/tracing and /sys/kernel/debug/tracing are writable only by trusted administrators.
• Temporarily disable SMC message tracepoints if they are not required for active troubleshooting or monitoring.
• Disable SMC/SMC-D or loopback ISM support on systems that do not need it, following vendor guidance.
• Monitor kernel logs for oops, general protection fault, KASAN NULL pointer dereference, and trace_event_raw_event_smc_msg_event stack traces.
• After patching, confirm systems are booted into the fixed kernel version; schedule reboots where updated kernels are installed but not active.
• Treat evidence of repeated local triggering as a potential insider, compromised account, or post-compromise denial-of-service activity, even though no public exploitation or ransomware use is currently indicated.