CVE-2024-56688

What it actually does

Failure to clear XPRT_SOCK_UPD_TIMEOUT after setting transport->sock to NULL during reset allows xs_tcp_set_socket_timeouts to dereference a NULL pointer in xs_tcp_send_request, resulting in a kernel NULL dereference and memory corruption.

Why it matters to the business

Systems running affected Linux kernels may experience kernel panics or crashes in NFS/RPC services, leading to service outages and requiring reboots; the high number of downstream dependents increases widespread operational risk.

How an attack unfolds

An attacker with local access triggers transport reset to set sock to NULL without clearing the timeout flag, then causes xs_tcp_send_request to invoke xs_tcp_set_socket_timeouts which dereferences the NULL pointer, potentially leading to denial of service or further memory corruption; listed threat actors in espionage and financial campaigns have targeted similar Linux kernel resource issues.

How to fix it

Update to a fixed kernel containing commit cc91d59d34ff6a6fee1c0b48612081a451e05e9a; for listed packages apply the corresponding fixed versions such as imagemagick 8:6.9.7.4+dfsg-16ubuntu2 where applicable.

How to confirm the fix worked

Verify kernel source contains the clearing of XPRT_SOCK_UPD_TIMEOUT in reset transport path and confirm no NULL dereference occurs in xs_tcp_send_request after reset; test with RPC transport reset followed by send operations.

Typical attack path

1. Obtain local access or trigger RPC transport operations on affected kernel
2. Cause reset of the transport to set sock to NULL
3. Initiate TCP send request that checks the uncleared XPRT_SOCK_UPD_TIMEOUT flag
4. Trigger NULL dereference in xs_tcp_set_socket_timeouts leading to crash

How to detect it

Review kernel logs for NULL pointer dereference oops in sunrpc or xs_tcp functions; correlate with RPC transport reset events and send request activity; threat actor context suggests watching for anomalous RPC traffic from espionage or financially motivated campaigns.

What your security team should do

• Prioritize patching Linux kernel to the fixed commit within standard update cycles given the 653 days since publication and low but persistent EPSS
• Monitor for kernel oops or panics in sunrpc/NFS code paths
• Apply updates to all affected stable kernels and downstream packages