CVE-2026-90235: sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: xprtsock: annotate shared socket callbacks with READONCE/WRITEONCE
xprtsock replaces and restores sk->skdataready and sk->skwritespace on live sockets with plain stores, and xsudpdosetbuffersize() invokes sk->skwritespace 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 READONCE()/WRITEONCE() callback visibility contract that the validated 4022 family applied elsewhere.
When SUNRPC takes over an AFLOCAL, 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 xsdataready() or xsudpwritespace() after the live callback fields have already been restored to the lower-socket handlers.
Use WRITEONCE() for the shared skdataready and skwritespace stores in xslocalfinishconnecting(), xsudpfinishconnecting(), xstcpfinishconnecting(), and xsrestoreoldcallbacks(). Use READONCE() for the direct skwritespace invocation in xsudpdosetbuffersize(). This matches the required callback visibility contract while leaving adjacent skstatechange and skerrorreport handling unchanged.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the validated callback replace/restore paths, annotate the shared socket callbacks sk_data_ready and sk_write_space to use WRITE_ONCE(), and use READ_ONCE() for the direct sk_write_space invocation. This fixes the callback visibility contract issue for concurrent protocol paths (e.g., when SUNRPC takes over sockets and later restores lower-socket handlers during teardown).
Linux kernel (socket callbacks) Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space callbacks; use READ_ONCE() for the direct sk_write_space invocation in the plain replace/restore callback handling = WRITE_ONCE()/READ_ONCE() - Configuration
Ensure xprtsock replaces/restores sk->sk_data_ready and xprtsock callback fields (e.g., in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks()) with READ_ONCE()/WRITE_ONCE() semantics so stale snapshots cannot concurrently invoke older callback snapshots (e.g., xs_data_ready).
Linux kernel (xprtsock restore/replace paths) Callback visibility contract for xprtsock callback restore/teardown = Use READ_ONCE()/WRITE_ONCE() on shared callback pointers - Configuration
Update xs_udp_do_set_buffer_size() / xs_udp_write_space() so that the sk->sk_write_space callback is invoked using the same READ_ONCE()/WRITE_ONCE() callback visibility contract, preventing concurrent plain stores from allowing invocation of a stale callback snapshot.
Linux kernel (UDP buffer sizing/write space) Callback invocation visibility for xs_udp_do_set_buffer_size() = Use READ_ONCE()/WRITE_ONCE() callback access semantics
Event History
Frequently Asked Questions
Which socket types are involved?
The affected callback handling applies when SUNRPC takes over AF_LOCAL, UDP, or TCP sockets and later restores the lower-socket callbacks during teardown.
What conditions are needed for the race to occur?
Another CPU must concurrently read or invoke the shared socket callbacks while xprtsock replaces or restores sk_data_ready or sk_write_space. A CPU can retain an earlier callback snapshot and invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have been restored.
Can the affected kernel versions be identified from this information?
No affected version range is provided. The listed stable kernel commits are the available remediation references.