Linux Kernel EUVD-2026-38711

Two conditions must both be true: first, the smc_msg_event tracepoint (backing smc_tx_sendmsg or smc_rx_recvmsg) must be explicitly enabled, which requires root access to the kernel tracing subsystem (typically via /sys/kernel/tracing/events/smc/); second, the system must support the SMC-D transport path - available natively on s390 or on x86 only when the ISM loopback device (ism.ko) is loaded. Once these conditions exist, any unprivileged user who can call socket(AF_SMC, ...) can trigger the crash without any further capability, because AF_SMC has no capability check. Limiting factors: SMC-D is not enabled in default x86 kernel deployments without explicit ISM module loading; tracepoints are off by default and enabling them requires root; environments not running SMC-D workloads are entirely unexploitable regardless of tracepoint state.

CVSS scores this 5.5 (Medium) at AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. The availability-only impact (kernel panic/crash) and local attack vector are consistent with the description. However, there is a meaningful nuance the raw CVSS does not capture: enabling the tracepoint requires root, creating a two-actor privilege chain where a privileged operator enables diagnostics and a subsequent unprivileged user triggers the crash. EPSS at 0.16% (6th percentile) indicates very low likelihood of exploitation in the wild, consistent with the absence of any KEV listing or referenced POC code. Real-world impact is concentrated on environments actively using SMC-D - primarily s390 mainframes and x86 systems that explicitly load the loopback ISM module - limiting the exposed population considerably. Systems that do not use SMC-D or do not enable these specific tracepoints are not exploitable. This is a genuine crash-class bug worth patching, but not an emergency priority outside those deployment contexts.

A kernel developer or site-reliability engineer enables the smc_rx_recvmsg tracepoint on an x86 production server running the loopback ISM module for SMC-D workload debugging. A local unprivileged user or competing container workload then opens an AF_SMC socket; the SMC handshake selects the SMC-D path, and the first recvmsg() call hits the tracepoint, which dereferences the NULL conn->lnk field while formatting the device name - crashing the kernel and taking down all workloads on the host. No public exploit code is referenced; the crash is directly reproducible from the code path documented in the CVE.