Description

In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-15T13:17:53.917Z",
  "pubdate": "2026-08-15T13:17:53.917Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel Transparent Inter-Process Communication (TIPC) subsystem, specifically within the socket poll trace queue dumping mechanism. The flaw is classified as a concurrency-related memory safety issue arising from missing synchronization during tracepoint execution. The impact of this vulnerability includes potential kernel memory corruption, system crashes, and theoretically, local privilege escalation if reliable exploitation primitives can be constructed. The affected system is the Linux kernel utilizing TIPC sockets. Risk implications are moderate to high depending on local system access and kernel configuration, as it requires an attacker to execute code that invokes tipc_poll() concurrently with socket queue modifications. Exploitation requirements involve triggering the unlocked poll trace path while another execution context concurrently dequeues and frees socket buffer (skb) elements, leading to a stale pointer dereference in the tracing subsystem.",
  "technicalDetails": "The vulnerability resides in the TIPC socket tracepoint implementation within the Linux kernel networking subsystem. Specifically, TIPC socket tracepoints utilize tipc_sk_dump() to dump queue states for diagnostic and debugging purposes. While most queue-dumping call sites properly serialize their memory walk operations by holding the appropriate socket lock or sk->sk_lock.slock, the tipc_poll() function invokes trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without acquiring either required lock.\nThe root cause is a race condition resulting from inadequate locking semantics during trace event generation. Because tipc_poll() invokes the trace helper from an unlocked context, the trace path proceeds to call tipc_list_dump() and execute backlog head and tail dumping on live socket queues. Concurrently, another execution context can dequeue and free a socket buffer (skb) from the queue. This asynchronous memory deallocation leaves the trace helper dereferencing a stale queue entry, resulting in a classic use-after-free condition.\nThe attack flow proceeds as follows: First, an execution context initiates a polling operation on a TIPC socket via tipc_poll(), which triggers the tracepoint trace_tipc_sk_poll with dump flags enabled without holding the socket lock. Second, while the trace helper iterates over the queue entries via tipc_list_dump() to inspect queue states, a separate concurrent thread or interrupt context modifies the queue by dequeuing and freeing an skb. Third, the trace helper attempts to access the memory address of the previously freed queue entry, resulting in a use-after-free condition. Depending on kernel heap allocations and timing, this can lead to kernel panics or undefined behavior.\nThe vulnerable component is the TIPC socket tracing mechanism within the Linux kernel networking subsystem. The affected functions include tipc_poll() and trace_tipc_sk_poll(). The vulnerability manifests due to missing synchronization primitives rather than network exposure, meaning network-based exploitation depends on whether TIPC ports are reachable or exposed. Authentication and privilege requirements are minimal for triggering the local poll path, but exploitation of kernel use-after-free bugs typically requires local execution capabilities to interact with TIPC sockets."
}