CVE-2026-99116 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net: psp: do not inherit the Rx association on clone
sk->psp_assoc sits past sk_dontcopy_end, so sock_copy() copies it into every socket accepted from a listener without taking a reference, while inet_sock_destruct() puts for every inet socket. psp_twsk_init() does refcount_inc() for the timewait socket, so a child closing through TIME_WAIT cancels its own put and leaves the association with one reference and N timewait sockets holding the same pointer. Closing the listener frees it, and the timewait timers then put freed memory.
Rejecting the association on a listening socket is not sufficient: a socket can acquire one while established and then be turned back into a listener, because tcp_disconnect() leaves sk->psp_assoc in place.
BUG: KASAN: slab-use-after-free in psp_twsk_assoc_free+0x6f/0xf0 Write of size 4 at addr ffff888110f9255c by task swapper/7/0 psp_twsk_assoc_free+0x6f/0xf0 inet_twsk_put+0xda/0x1b0 call_timer_fn+0x53/0x2e0 __run_timers+0x764/0xa80 Freed by task 99: kfree+0x1a7/0x500 process_one_work+0x7ec/0x1100
An association carries a per-connection SPI and key, so a child must not inherit the parent's. Clear it on clone.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel network stack contains a critical use-after-free vulnerability within the PSK (Preshared Key) implementation for IPsec connections, specifically affecting how socket associations are handled during socket cloning and state transitions. The core technical flaw lies in the interaction between sock_copy(), which is invoked when accepting new connections from a listening socket, and the reference counting mechanisms of the psp_assoc structure. In the kernel's memory management model, sk_dontcopy_end marks the boundary beyond which fields should not be copied during socket duplication to prevent unintended sharing of resources that require independent lifecycle management. However, the sk_psp_assoc pointer resides past this boundary, causing sock_copy() to blindly duplicate the pointer into every newly accepted child socket without incrementing its reference count. This creates a scenario where multiple sockets share the same underlying association object while only one entity is responsible for releasing it via inet_sock_destruct().
The vulnerability manifests through a complex sequence of events involving TCP time-wait states and listener socket lifecycle management. When a connection transitions to TIME_WAIT, psp_twsk_init() correctly increments the reference count on the association. However, when these child sockets close or expire from their time-wait state, they invoke inet_twsk_put(), which decrements the reference count. Because multiple children share the same pointer without individual references, this leads to premature deallocation of the shared psp_assoc structure while other active or pending timers still hold pointers to it. Specifically, when a child socket closes through TIME_WAIT, it cancels its own put operation but leaves the association with an incorrect reference state relative to the remaining timewait sockets holding the same pointer. Subsequently, when the original listener socket is closed and frees the association memory via kfree(), any subsequent expiration of timers associated with those orphaned time-wait sockets triggers psp_twsk_assoc_free(). This function attempts to write to or access the already freed memory address, resulting in a kernel slab-use-after-free error as evidenced by KASAN reports showing writes to addresses that have been returned to the allocator.
The complexity of this vulnerability is exacerbated by socket state transitions that bypass standard acceptance logic. Simply rejecting association inheritance on listening sockets is insufficient mitigation because TCP disconnect operations can leave sk_psp_assoc intact even after a connection is torn down. If such a socket is subsequently reused or turned back into a listener, it retains the stale pointer to the previous association's resources. This means that new connections accepted from this recycled listener will inherit an invalid reference to memory that may have been freed by the previous incarnation of the connection context. The operational impact includes kernel panics due to slab corruption, potential denial-of-service conditions affecting system stability, and theoretically exploitable arbitrary write primitives if an attacker can control the data written during the use-after-free window in psp_twsk_assoc_free.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free, as it involves accessing memory after it has been freed due to incorrect reference counting management. It also relates to CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization, given the race-like conditions between timer callbacks and socket destruction paths that lead to inconsistent state regarding resource ownership. In terms of MITRE ATT&CK mapping, this represents a technique often leveraged in exploitation chains for privilege escalation or code execution via kernel memory corruption, specifically falling under Taint Analysis and Memory Corruption categories where improper handling of shared resources leads to security bypasses.
To mitigate this vulnerability, the primary remediation is to ensure that socket cloning operations do not inherit the psp_assoc pointer from parent sockets unless explicitly managed with proper reference counting increments. The fix involves clearing sk_psp_assoc during the clone operation in sock_copy() or ensuring that any inherited association carries a fresh reference count increment so that each socket independently manages its lifecycle. Additionally, developers must ensure that tcp_disconnect() and similar state transition functions properly nullify or detach associations to prevent stale pointers from persisting when sockets are reused as listeners. System administrators should apply the latest kernel patches that include this fix immediately to restore memory safety guarantees within the network stack. Regular auditing of socket reference counting logic in other subsystems is recommended to identify similar patterns where shared resources are duplicated without corresponding refcount adjustments, which could lead to analogous vulnerabilities across different protocol implementations.