Bug 2436805 (CVE-2026-23066)

Summary: CVE-2026-23066 kernel: Linux kernel: Denial of Service via unsafe requeue in rxrpc_recvmsg
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel. A local unprivileged process can exploit an unsafe requeue path in the `rxrpc_recvmsg` function by using `AF_RXRPC` sockets with `MSG_DONTWAIT` and `MSG_PEEK` flags. This improper handling of the receive message queue can lead to memory corruption, such as Use-After-Frees (UAFs) or reference count underruns. The most likely outcome is a kernel crash or memory safety warning, resulting in a denial of service. There is also a conservative possibility of broader impact if the memory corruption is exploitable.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-02-04 17:04:15 UTC 
In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix recvmsg() unconditional requeue

If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at
the front of the recvmsg queue already has its mutex locked, it requeues
the call - whether or not the call is already queued.  The call may be on
the queue because MSG_PEEK was also passed and so the call was not dequeued
or because the I/O thread requeued it.

The unconditional requeue may then corrupt the recvmsg queue, leading to
things like UAFs or refcount underruns.

Fix this by only requeuing the call if it isn't already on the queue - and
moving it to the front if it is already queued.  If we don't queue it, we
have to put the ref we obtained by dequeuing it.

Also, MSG_PEEK doesn't dequeue the call so shouldn't call
rxrpc_notify_socket() for the call if we didn't use up all the data on the
queue, so fix that also.
Comment 1 Jon Moroney 2026-02-04 21:18:50 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026020416-CVE-2026-23066-8e44@gregkh/T
Comment 3 errata-xmlrpc 2026-04-20 18:11:46 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10.0 Extended Update Support

Via RHSA-2026:9095 https://access.redhat.com/errata/RHSA-2026:9095
Comment 4 errata-xmlrpc 2026-04-20 20:28:54 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.6 Extended Update Support

Via RHSA-2026:9112 https://access.redhat.com/errata/RHSA-2026:9112
Comment 5 errata-xmlrpc 2026-04-22 00:11:14 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:9512 https://access.redhat.com/errata/RHSA-2026:9512
Comment 6 errata-xmlrpc 2026-04-22 08:05:07 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:9644 https://access.redhat.com/errata/RHSA-2026:9644
Comment 7 errata-xmlrpc 2026-04-23 22:46:37 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.4 Extended Update Support

Via RHSA-2026:10108 https://access.redhat.com/errata/RHSA-2026:10108