CVE-2026-74434

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Don&amp;#39;t move a peeked OOB message onto the pending queue<br /> <br /> rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and,<br /> if a response is needed, moves it onto the pending_oobq tree. However,<br /> only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto<br /> pending_oobq always runs.<br /> <br /> As a result, reading a challenge with MSG_PEEK leaves the skb on<br /> recvmsg_oobq while also adding it to pending_oobq. Since struct<br /> sk_buff&amp;#39;s rbnode shares storage with its next and prev pointers,<br /> rb_insert_color() overwrites the list linkage, and the skb, which holds<br /> a single reference, becomes reachable from both queues at once.<br /> <br /> When the socket is closed both queues are drained in turn. While<br /> draining recvmsg_oobq, __skb_unlink() follows the next and prev<br /> pointers that rbnode has overwritten and writes to a bad address. Also,<br /> as the skb holds a single reference but is freed from each queue, both<br /> the skb and the connection reference it holds are released twice. This<br /> leads to memory corruption and to a use-after-free caused by the<br /> connection refcount underflow.<br /> <br /> MSG_PEEK does not consume the message from the queue, so only unlink it<br /> from recvmsg_oobq and then move it onto pending_oobq or free it when<br /> the message is actually consumed.