CVE-2026-74434

This CVE exposes a failure mode in kernel queue handling that conventional testing likely missed not because the code path is exotic, but because the vulnerability lives in the interaction between two semantically distinct queue operations under MSG_PEEK — a flag whose scope was underspecified in both documentation and developer mental models. The rxrpc out-of-band handling code makes a classic assumption: MSG_PEEK is a local, scoped operation affecting only the immediate unlink from recvmsg_oobq, not a semantic constraint on what can happen downstream. The code guards the unlink with MSG_PEEK but moves the message onto pending_oobq unconditionally. When MSG_PEEK is set, the message remains on the recv queue but gets simultaneously threaded onto the pending queue — and since rbnode and list linkage (next/prev) share the same storage in sk_buff, the rb_insert_color() call silently overwrites the list pointers that other code is still using. The result is a use-after-free on the message buffer that manifests as a connection refcount underflow. The storage overlap between rbnode and list linkage is a legitimate kernel optimization but creates implicit coupling between distant code paths. A developer adding the pending_oobq move likely didn't trace what rb_insert_color() would do to a buffer already threaded onto a list. MSG_PEEK was treated as "don't remove from this queue" rather than "don't alter the message's structural state in any way." The blast radius here exceeds a typical memory corruption. rxrpc connections participate in credential and key management for Kerberos ticket caching. A corrupted refcount doesn't just crash the local path — it poisons any kernel code that touches the connection object afterward, potentially corrupting security contexts downstream. For defenders: audit any code path where MSG_PEEK guards an unlink or read but leaves downstream queue manipulations unconditional. Search for similar dual-queue patterns in other network subsystems. The underlying genotype — shared polymorphic storage plus conditional mutations on only part of a multi-step operation — has surfaced in multiple kernel subsystems under different flags. This CVE is likely not an isolated flaw but another expression of a recurring semantic underspecification that the kernel has never formally addressed in API documentation.

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