CVE-2026-80984: Linux Kernel Use-After-Free Vulnerability

CVE-2026-80984 Overview

CVE-2026-80984 is a NULL pointer dereference vulnerability in the Linux kernel's Shared Memory Communications Direct (SMC-D) socket subsystem. The flaw resides in smc_close_stream_wait(), which calls smc_tx_prepared_sends() inside its sk_wait_event() condition. Because sk_wait_event() evaluates the condition once with the socket lock released, a concurrent link group teardown via smcd_buf_detach() can clear conn->sndbuf_desc while the helper is still dereferencing it. The result is a kernel fault during socket close(). The SIOCOUTQ ioctl reads the same field without protection, and smc_close_cancel_work() drops the lock across two cancel_*_sync() calls, widening the race window.

Critical Impact
A local unprivileged process using SMC-D sockets can trigger a kernel NULL pointer dereference during connection teardown, producing a denial-of-service condition on affected Linux systems.

Affected Products

Linux kernel versions containing the SMC-D socket implementation prior to the referenced fix commits
Distributions shipping the upstream net/smc module
Systems using SMC-D (Shared Memory Communications over ISM devices), commonly on IBM Z hardware

Discovery Timeline

2026-09-11 - CVE-2026-80984 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-80984

Vulnerability Analysis

The defect is a race between socket teardown and link group termination in the net/smc subsystem. smc_close_stream_wait() uses sk_wait_event() to block until the transmit buffer drains. The wait macro releases the socket lock while sleeping and re-evaluates its condition without holding the lock on at least one path. The condition callback invokes smc_tx_prepared_sends(), which dereferences conn->sndbuf_desc to compute the count of pending bytes.

Concurrently, smcd_buf_detach() runs from smc_conn_kill() under lock_sock() when the SMC-D link group is being torn down. It sets conn->sndbuf_desc to NULL. If the closing socket's condition evaluation observes the cleared pointer, the helper faults inside close(). The SIOCOUTQ ioctl handler reads the same field directly, presenting an equivalent unsafe access. smc_close_cancel_work() further compounds exposure by dropping the socket lock across successive cancel_work_sync() and cancel_delayed_work_sync() calls.

Root Cause

The root cause is unsynchronized access to conn->sndbuf_desc across teardown paths. The producer of the NULL store (smcd_buf_detach()) holds the socket lock, but the consumers in smc_tx_prepared_sends() and the SIOCOUTQ handler can execute without it. This is a classic NULL pointer dereference driven by a Time-of-Check to Time-of-Use pattern on a shared connection field.

Attack Vector

The attack vector is local. A process holding an SMC-D socket must trigger close() (or issue SIOCOUTQ) while the associated link group is terminated, for example by peer disconnect or device removal. The upstream fix samples the pointer once inside the helper, reports "nothing prepared" when it is unset, and applies the same bounding to the ioctl path. The receive tasklet path in smc_cdc_msg_recv_action() dereferences the field directly and is addressed by a companion patch in the series.

See the upstream fix commits for the exact code changes: Kernel Commit ab26e12, Kernel Commit b395dd3, Kernel Commit e3fcff8, Kernel Commit f517cf0, and Kernel Commit f950e1b.

Detection Methods for CVE-2026-80984

Indicators of Compromise

Kernel oops or panic messages referencing smc_tx_prepared_sends, smc_close_stream_wait, or smcd_buf_detach in dmesg or the system journal
Unexpected process termination or hangs on workloads using SMC-D sockets, particularly during peer disconnects or device removal events
Repeated NULL pointer dereference traces originating from the net/smc module

Detection Strategies

Aggregate kernel crash telemetry (kdump, pstore, systemd-coredump) and alert on stack frames within the net/smc module
Monitor for processes issuing SIOCOUTQ ioctls on AF_SMC sockets in environments where SMC-D is enabled
Track loaded kernel versions against the fixed upstream commits to identify hosts still exposed

Monitoring Recommendations

Enable persistent kernel log collection and forward dmesg output to a centralized data lake for search and correlation
Baseline SMC-D usage across the fleet; investigate hosts where SMC socket activity appears without an operational need
Correlate SMC link group termination events with socket close failures to identify race-condition attempts

How to Mitigate CVE-2026-80984

Immediate Actions Required

Apply the upstream stable kernel updates that include commits ab26e12, b395dd3, e3fcff8, f517cf0, and f950e1b
Inventory hosts that load the smc kernel module and prioritize patching on IBM Z and other systems using SMC-D
Disable SMC-D where it is not required by unloading the smc module and blacklisting it in modprobe configuration

Patch Information

The fix samples conn->sndbuf_desc once inside smc_tx_prepared_sends(), treats an unset pointer as "nothing prepared," and applies the same bounding to the SIOCOUTQ ioctl handler. Distribution kernels should be updated to versions that backport the listed commits. Consult vendor advisories from Red Hat, SUSE, Ubuntu, and Debian for backport availability.

Workarounds

Blacklist the smc module on systems that do not require SMC-D connectivity
Restrict AF_SMC socket creation using seccomp or LSM policies on multi-tenant systems
Avoid running workloads that rely on SMC-D socket teardown paths on unpatched kernels

bash

# Disable and blacklist the SMC kernel module
sudo modprobe -r smc
echo 'blacklist smc' | sudo tee /etc/modprobe.d/blacklist-smc.conf
sudo update-initramfs -u

# Verify the module is not loaded after reboot
lsmod | grep -E '^smc'