Cloudanix VulnDB

CVE-2026-99054

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's TIPC networking code can let a local user crash the system or potentially gain elevated access.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition during TIPC topology server shutdown allows socket callbacks and subscription events to queue work after workqueues are destroyed, producing refcount underflow, use-after-free in connection teardown, queue_work on destroyed workqueues, and RCU stalls under idr_lock.

Why it matters to the business

Local users on affected Linux systems can trigger kernel crashes or memory corruption, resulting in denial of service and potential local privilege escalation on servers or containers using the TIPC protocol.

How an attack unfolds

An attacker with local access loads or exercises the TIPC module, initiates topology server stop, and times concurrent connection events to hit the window where the listener flag is not yet cleared and workqueues are still active, leading to the described teardown failures.

How to fix it

Apply the upstream kernel patch that clears the listener under idr_lock, refuses lookups after the shutdown flag, destroys workqueues before closing connections, and drops idr_lock on empty walks; rebuild and deploy the fixed kernel.

How to confirm the fix worked

Boot the patched kernel, exercise TIPC topology server start/stop under load with concurrent subscriptions, and confirm absence of refcount warnings, use-after-free reports, or RCU stalls in dmesg and kernel logs.

Typical attack path

  1. Obtain local code execution on a system with TIPC enabled
  2. Trigger or wait for tipc_topsrv_stop execution path
  3. Race subscription events and connection close against workqueue destruction
  4. Trigger refcount misuse or use-after-free to crash or corrupt kernel state

How to detect it

Search kernel logs and crash dumps for TIPC-related refcount underflow, use-after-free in tipc_conn_close, queue_work on destroyed workqueues, or RCU stalls inside tipc_topsrv_exit_net; correlate with processes that recently used TIPC sockets.

  • refcount_t: addition on 0
  • tipc_conn_close
  • tipc_topsrv_exit_net
  • queue_work on already destroyed workqueue
  • RCU stall.*idr_lock

What your security team should do

  • Prioritize kernel updates containing the TIPC teardown ordering fix within the next patch cycle
  • Restrict untrusted local users and containers from loading the TIPC module where feasible
  • Add kernel oops and TIPC-specific panic monitoring to existing alerting
  • Test the fix in staging environments that exercise TIPC before production rollout

The record

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.

Affected packages

Ecosystem Package Introduced Fixed