Description

The RACK setsockopt(2) handler drops the connection lock in order to copy option data from userspace, then reacquires the lock. After reacquiring, it verifies that the TCP stack had not been switched away, but did not reload its pointer to the stack's per-connection control block. If userspace switches stacks twice during this window, the check will succeed but the saved pointer will refer to freed memory. The bug may be exploitable by an unprivileged local user to escalate privileges.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-19T06:17:41.447Z",
  "pubdate": "2026-08-19T06:17:41.447Z",
  "executiveSummary": "A use-after-free vulnerability exists within the RACK setsockopt(2) handler in the Linux TCP network stack implementation. The vulnerability stems from improper handling of connection locks and stale pointer references when userspace concurrently modifies the active TCP stack. An unprivileged local attacker can exploit this flaw to achieve local privilege escalation.\nThe vulnerability type is classified as a use-after-free condition driven by a race window during socket option configuration. The impact of successful exploitation includes arbitrary code execution within kernel space, potentially leading to a complete compromise of the affected operating system. The affected systems encompass implementations utilizing the RACK TCP congestion control and recovery mechanisms where socket state transitions can occur during system calls.\nThe attacker capabilities required to exploit this vulnerability are limited to unprivileged local user access, meaning an attacker must possess the ability to execute code locally on the target system. Exploitation requirements involve winning a precise race condition by manipulating the TCP stack via setsockopt(2) calls while the connection lock is temporarily dropped. Risk implications are critical due to the potential for kernel-level code execution and system instability.",
  "technicalDetails": "The vulnerability resides in the setsockopt(2) system call handler associated with the RACK TCP recovery mechanism. The root cause of the flaw is a combination of lock dropping during userspace data copying and subsequent failure to reload critical internal pointers upon lock reacquisition.\nDuring the execution of the setsockopt(2) handler, the kernel drops the connection lock to safely copy option data from userspace memory into kernel space. After completing the copy operation, the kernel reacquires the connection lock and performs a validation check to ensure that the underlying TCP stack has not been switched away during the interim window. However, while this check verifies that the stack type remains unchanged, it fails to reload the cached pointer referencing the stack's per-connection control block.\nExploitation occurs when an unprivileged local user initiates a sequence of events where the TCP stack is switched twice during the critical window while the connection lock is dropped. Because the stack is switched twice, the initial pointer check succeeds by observing a matching stack identifier, but the saved pointer actually points to a previously freed memory region associated with the original control block. Subsequent operations utilizing this stale pointer result in a use-after-free condition.\nThe attack flow unfolds through the following step-by-step mechanism: 1) The local attacker invokes setsockopt(2) targeting a socket using the RACK stack. 2) The kernel drops the connection lock to copy user data. 3) The attacker leverages concurrent threads or asynchronous operations to switch the TCP stack twice on the same socket within the race window. 4) The setsockopt(2) handler resumes, reacquires the connection lock, and validates the stack type. 5) The validation succeeds based on the re-selected stack type, but the control block pointer remains stale, referencing the freed memory of the intermediate or original structure. 6) The kernel dereferences the dangling pointer, triggering a use-after-free condition that can be manipulated by heap grooming techniques to achieve kernel code execution and privilege escalation."
}