Microsoft Security Response Center guidance
Vendor revision: Oct 21, 2026Release Notes
Vendor-listed releases
- 6.6.157.1-1
Vulnerability intelligence
CVE-2026-90235 and is rated Critical severity with a CVSS score of 9.8. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.
Release Notes
Vendor-listed releases
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.
Source: NVD