{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-74434","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-08-15T05:44:03.896Z","datePublished":"2026-08-15T05:59:33.438Z","dateUpdated":"2026-08-17T05:47:08.797Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-17T05:47:08.797Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Don't move a peeked OOB message onto the pending queue\n\nrxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and,\nif a response is needed, moves it onto the pending_oobq tree. However,\nonly the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto\npending_oobq always runs.\n\nAs a result, reading a challenge with MSG_PEEK leaves the skb on\nrecvmsg_oobq while also adding it to pending_oobq. Since struct\nsk_buff's rbnode shares storage with its next and prev pointers,\nrb_insert_color() overwrites the list linkage, and the skb, which holds\na single reference, becomes reachable from both queues at once.\n\nWhen the socket is closed both queues are drained in turn. While\ndraining recvmsg_oobq, __skb_unlink() follows the next and prev\npointers that rbnode has overwritten and writes to a bad address. Also,\nas the skb holds a single reference but is freed from each queue, both\nthe skb and the connection reference it holds are released twice. This\nleads to memory corruption and to a use-after-free caused by the\nconnection refcount underflow.\n\nMSG_PEEK does not consume the message from the queue, so only unlink it\nfrom recvmsg_oobq and then move it onto pending_oobq or free it when\nthe message is actually consumed."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":9.8,"baseSeverity":"CRITICAL"},"scenarios":[{"lang":"en","value":"AV:N - A remote RxRPC/AFS peer can deliver CHALLENGE packets over UDP to a victim AF_RXRPC client socket; those packets are queued for recvmsg() handling, so the vulnerable rxrpc_recvmsg_oob() path is reached from network-driven authentication traffic rather than purely local-only APIs.\nAC:L - An attacker who controls both ends of the connection (or a malicious remote server and a userspace client) can reliably queue a CHALLENGE, call recvmsg(MSG_PEEK) with RXRPC_MANAGE_RESPONSE enabled, then close the socket to trigger duplicate queueing and deterministic double-free/UAF during OOB queue purge.\nPR:N - Exploitation requires no privileges on the victim host beyond what any unauthenticated remote RxRPC/AFS server already has to send protocol packets during connection security negotiation; no CAP_NET_ADMIN, root, or namespace-admin capability is needed on the target system.\nUI:N - No victim user interaction is required beyond normal automated RxRPC/AFS client operation that receives and processes authentication challenges from a server; the attacker does not need the victim to perform a separate manual action beyond routine client-server communication.\nS:U - The corrupted component is kernel RxRPC socket state and the impact is kernel memory corruption and privilege escalation within the same kernel security authority, not a cross-boundary escape such as a VM or sandbox breakout.\nC:H - The bug leaves one sk_buff referenced from both recvmsg_oobq and pending_oobq, causing double free and rxrpc_connection refcount underflow; this is a use-after-free/memory-corruption primitive that can expose or read freed kernel heap contents.\nI:H - rb_insert_color() overwrites sk_buff list linkage shared with rbnode, and socket teardown calls __skb_unlink() on corrupted pointers leading to out-of-bounds writes, enabling control of freed objects and potential arbitrary kernel code execution.\nA:H - Closing the socket drains both OOB queues and reliably triggers invalid pointer writes, skb double-free, and connection refcount underflow, producing kernel oops/panic and complete loss of system availability even without full exploitation."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/rxrpc/recvmsg.c"],"versions":[{"version":"5800b1cf3fd8ccab752a101865be1e76dac33142","lessThan":"9ada3931beb37068fcb725b34b0398457009f343","status":"affected","versionType":"git"},{"version":"5800b1cf3fd8ccab752a101865be1e76dac33142","lessThan":"5f470cc883416fea6d3bce18ef96bf91dd49ffc3","status":"affected","versionType":"git"},{"version":"5800b1cf3fd8ccab752a101865be1e76dac33142","lessThan":"5801cff7d5d7b4e9d877dfb627b23eb63167f02c","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/rxrpc/recvmsg.c"],"versions":[{"version":"6.16","status":"affected"},{"version":"0","lessThan":"6.16","status":"unaffected","versionType":"semver"},{"version":"6.18.40","lessThanOrEqual":"6.18.*","status":"unaffected","versionType":"semver"},{"version":"7.1.5","lessThanOrEqual":"7.1.*","status":"unaffected","versionType":"semver"},{"version":"7.2","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.16","versionEndExcluding":"6.18.40"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.16","versionEndExcluding":"7.1.5"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.16","versionEndExcluding":"7.2"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/9ada3931beb37068fcb725b34b0398457009f343"},{"url":"https://git.kernel.org/stable/c/5f470cc883416fea6d3bce18ef96bf91dd49ffc3"},{"url":"https://git.kernel.org/stable/c/5801cff7d5d7b4e9d877dfb627b23eb63167f02c"}],"title":"rxrpc: Don't move a peeked OOB message onto the pending queue","x_generator":{"engine":"bippy-1.2.0"}}}}