CVE-2026-74434: rxrpc: Don't move a peeked OOB message onto the pending queue

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Don't move a peeked OOB message onto the pending queue

rxrpcrecvmsgoob() takes a received oob message off recvmsgoobq and, if a response is needed, moves it onto the pendingoobq tree. However, only the unlink from recvmsgoobq is guarded by MSGPEEK; the move onto pendingoobq always runs.

As a result, reading a challenge with MSGPEEK leaves the skb on recvmsgoobq while also adding it to pendingoobq. Since struct skbuff's rbnode shares storage with its next and prev pointers, rbinsertcolor() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once.

When the socket is closed both queues are drained in turn. While draining recvmsgoobq, skbunlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow.

MSGPEEK does not consume the message from the queue, so only unlink it from recvmsgoobq and then move it onto pendingoobq or free it when the message is actually consumed.