CVE-2026-80984

What it actually does

A race in the Linux kernel SMC-D teardown path can leave smc_tx_prepared_sends() (and SIOCOUTQ) reading conn->sndbuf_desc after smcd_buf_detach() has cleared it. Because smc_close_stream_wait() evaluates its sk_wait_event() condition once without the socket lock, a concurrent link-group kill can produce a NULL pointer dereference in kernel context, typically oopsing or panicking the host during socket close rather than corrupting data in place.

Why it matters to the business

Impact is availability: hosts using Shared Memory Communications (SMC/SMC-D) can crash or lose networking during connection teardown, disrupting workloads that depend on that kernel. The issue is not listed in CISA KEV, has no reported ransomware use, exploit maturity is none, and EPSS remains about 0.0021 with no 30-day increase, so mass opportunistic exploitation is unlikely. Residual risk is highest on systems that actually run SMC (for example high-performance or IBM Z-style RDMA fabrics) rather than generic Internet-facing servers. Apply kernel updates on the normal patch cycle unless SMC is in production, in which case treat it as a stability fix.

How an attack unfolds

An attacker who can already run code or drive SMC sockets on the host races a closing SMC-D socket against link-group teardown. While one path waits in smc_close_stream_wait() with the socket lock dropped, another path kills the connection and detaches the send buffer. The waiter then samples a NULL send-buffer descriptor and the kernel faults. The same window can be hit via SIOCOUTQ or during smc_close_cancel_work() because it drops the lock across cancel_*_sync(). This is a local, timing-sensitive denial-of-service race, not a remote unauthenticated RCE path, and there are no named threat actors or in-the-wild campaigns associated with it.

How to fix it

Install a Linux kernel that contains the net/smc fix: sample sndbuf_desc once in smc_tx_prepared_sends(), treat an unset descriptor as zero prepared sends, and apply the same bound to SIOCOUTQ. Prefer distribution or vendor kernel packages that backported 'net/smc: do not dereference an unset send buffer on the SMC-D teardown path' rather than building from source. If an immediate upgrade is impossible, reduce exposure by disabling SMC where it is not required (for example via sysctl/module parameters that prevent SMC proposal on TCP), isolating SMC-capable hosts, and avoiding untrusted local users on those systems. Reboot into the patched kernel to complete remediation.

How to confirm the fix worked

Confirm the running kernel changelog or stable commit list includes the net/smc teardown NULL-deref fix, then reboot and verify uname -r matches the patched build. On patched kernels, closing SMC-D sockets while a link group is torn down should no longer oops in smc_tx_prepared_sends or during SIOCOUTQ. Systems that never load net/smc or never negotiate SMC are not exposed; lsmod, kernel config (CONFIG_SMC), and absence of SMC socket usage can be used to document that. Do not attempt to reproduce the race on production hosts.

Typical attack path

1. Obtain local execution or the ability to open and close SMC-D sockets on a vulnerable kernel
2. Establish an SMC-D connection so a send buffer descriptor is attached to the connection
3. Force the socket into smc_close_stream_wait() (or issue SIOCOUTQ / trigger close-work cancellation) so the wait condition runs without the socket lock
4. Concurrently terminate the link group so smc_conn_kill() / smcd_buf_detach() clears conn->sndbuf_desc
5. Cause the unlocked helper to dereference the now-NULL descriptor and crash the kernel

How to detect it

This race leaves a kernel oops, not a durable implant. Hunt historical and current kernel logs (journald/kern.log/dmesg, vmcore/kdump, crash dumps) for NULL-pointer dereferences whose stacks include SMC close or send-buffer helpers, especially around socket close, SIOCOUTQ, or link-group termination. Correlate with processes using SMC sockets and with sudden host reboots. There is no public exploit kit or named actor activity to key on; treat matching oopses after the publication date as possible triggering of the bug, whether accidental or malicious. Packet captures of SMC/RDMA teardown are supporting context only.

• NULL pointer dereference in smc_tx_prepared_sends
• oops / panic stack containing smc_close_stream_wait
• oops / panic stack containing smcd_buf_detach
• oops / panic stack containing smc_conn_kill
• kernel fault during SIOCOUTQ on an SMC socket
• oops / panic stack containing smc_close_cancel_work
• kernel log: net/smc and sndbuf_desc
• tasklet/stack reference to smc_cdc_msg_recv_action during SMC-D teardown

What your security team should do

• Inventory hosts with CONFIG_SMC / the smc module and any production SMC-D usage; patch and reboot those first
• Track vendor kernel advisories for this stable fix even though EPSS is low and the CVE is not in KEV
• If SMC is unused, keep the module unloaded or disabled to shrink the local DoS surface
• After patching, watch kernel logs for residual SMC oopses during close to confirm the race is gone
• Do not prioritize emergency change windows solely on this CVE unless SMC teardown crashes are already occurring