CVE-2026-74431

CVE-2026-74431 is an infinite loop vulnerability in rxrpc_recvmsg() caused by the wait condition checking only the normal receive queue while ignoring the out-of-band (OOB) queue. When OOB data arrives on an rxrpc socket, the wait loop never wakes, creating a deterministic wedge that consumes CPU without making progress. The vulnerability exposes a design-level desynchronization in rxrpc's recvmsg architecture. The normal data path and the OOB path evolved separately and were never properly integrated into a unified wait condition. The fix—adding an OOB queue check to the wait—is deceptively simple, which suggests the developer understood the requirement but placed the check in the wrong code path. This is not a simple typo; it's an architectural oversight where two code paths operate with different visibility into available data. The blast radius extends beyond who can trigger the bug. An infinite loop in a kernel recvmsg path creates a progressive resource exhaustion condition. The affected kernel thread (whether a dedicated kworker or a process context handling other socket work) becomes wedged, causing socket accumulation, memory pressure, and silent system degradation. Unlike a crash, which is noisy and triggers recovery, this condition can run for extended periods before anyone notices NFS mounts lagging or the socket table growing. The OOB path in rxrpc carries historical sediment. Given that rxrpc primarily serves NFS over kAFS—a workload where OOB data is functionally never expected—the OOB queue may have become vestigial through partial deprecation rather than fresh regression. The check wasn't necessarily never added; it may have been removed during cleanup as dead code while the queue remained populated under specific conditions. Audit the rxrpc OOB path to determine whether it should be fully removed or rigorously integrated with proper wait conditions. If OOB handling is retained, blocking recvmsg paths must be tested under OOB delivery conditions—the standard recvmsg test suite will not catch this class of bug. Similar desynchronization patterns likely exist in other recvmsg implementations with auxiliary data paths; treat this finding as a canary for architectural debt in parallel data-source handling.

Reviewed through automated stages and approved by a human before publication.