CVE-2026-90235 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE
xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere.
When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers.
Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's SunRPC subsystem contains a concurrency vulnerability related to improper memory access synchronization when managing socket callbacks on live network connections. Specifically, the xprtsock module replaces standard socket data ready and write space callback pointers with custom handlers during connection establishment or buffer size adjustments, and subsequently restores the original lower-socket callbacks during teardown operations. This process involves direct assignment of function pointers within structures such as sk_data_ready and sk_write_space without employing atomic memory access primitives. In a multi-core environment where multiple CPUs may execute concurrently, this lack of explicit synchronization creates a race condition that violates standard visibility contracts for shared data accessed by both the SunRPC subsystem and generic socket protocol paths.
The technical flaw stems from the use of plain stores and loads when modifying or reading these callback pointers. When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket, it temporarily overrides the default handlers to manage RPC-specific logic. However, if a teardown operation restores the original callbacks while another CPU thread is still holding a stale snapshot of the previous handler pointer, that thread may invoke functions like xs_data_ready() or xs_udp_write_space() after the live callback fields have already been reverted to their lower-socket equivalents. This scenario results in undefined behavior because the code execution context no longer matches the state assumed by the invoked function, potentially leading to kernel panics, data corruption, or privilege escalation if an attacker can trigger this race condition through crafted network traffic that forces rapid connection setup and teardown cycles.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with inadequate synchronization. The failure to use READ_ONCE() and WRITE_ONCE() macros means the compiler or CPU may reorder memory operations in ways that expose intermediate states to other processors, violating the expected atomicity of pointer updates. In terms of adversarial tactics, this flaw could be leveraged within an ATT&CK framework context as part of a Denial of Service attack vector by crashing the kernel service layer, or potentially for privilege escalation if the stale callback invocation leads to execution in an unintended memory context with elevated privileges. The vulnerability highlights the critical importance of adhering to strict visibility contracts when modifying shared state in high-performance networking code paths that are subject to frequent concurrent access.
To mitigate this issue, developers must ensure that all accesses to shared socket callback pointers utilize READ_ONCE() for loads and WRITE_ONCE() for stores. This ensures that each read or write operation is treated as an atomic unit with respect to other CPUs, preventing the compiler from optimizing away necessary memory barriers and ensuring that changes are immediately visible across all processor cores involved in handling network packets. The fix involves annotating specific functions such as xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks() with WRITE_ONCE() for pointer assignments, and applying READ_ONCE() when invoking sk_write_space within contexts like xs_udp_do_set_buffer_size(). Maintaining this synchronization discipline preserves the integrity of socket state transitions and prevents stale callback invocations during concurrent teardown operations.