In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix double unlock in rxrpc_recvmsg()
Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - RxRPC processes CHALLENGE packets from remote UDP peers; with RXRPC_MANAGE_RESPONSE and RxGK security, a network peer can queue OOB challenges that are consumed on the next recvmsg() during normal client authentication (e.g., AFS/YFS).
AC:L - An attacker who is the RxRPC peer (or a local user running a malicious server) can reliably deliver a CHALLENGE and trigger recvmsg() on demand; no rare timing, layout, or victim state outside attacker control is required.
PR:N - No administrative capability is needed on the victim; any remote peer in an RxRPC connection can send CHALLENGE packets, and unprivileged local users can create AF_RXRPC sockets, set MANAGE_RESPONSE, and call recvmsg() without special privileges.
UI:N - Exploitation does not require victim interaction beyond normal automated RxRPC/AFS client operation; recvmsg() is invoked automatically when OOB challenges are queued during connection security negotiation.
S:U - Impact is confined to kernel memory and locking on the affected host; it does not cross VM, container, or IOMMU security boundaries into a separate authority.
C:H - Double release_sock() corrupts socket lock ownership, allowing concurrent unsynchronized access to socket/call state and adjacent kernel heap objects, which can be leveraged for arbitrary kernel memory disclosure.
I:H - The corrupted socket lock permits overlapping recvmsg()/sendmsg() access to connection and skb state, enabling heap corruption and control-flow hijack primitives typical of kernel locking bugs.
A:H - The double unlock triggers lockdep warnings and can panic/oops the kernel or hang socket I/O when concurrent threads access the same RxRPC socket after ownership is incorrectly cleared.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - RxRPC processes CHALLENGE packets from remote UDP peers; with RXRPC_MANAGE_RESPONSE and RxGK security, a network peer can queue OOB challenges that are consumed on the next recvmsg() during normal client authentication (e.g., AFS/YFS).
AC:L - An attacker who is the RxRPC peer (or a local user running a malicious server) can reliably deliver a CHALLENGE and trigger recvmsg() on demand; no rare timing, layout, or victim state outside attacker control is required.
PR:N - No administrative capability is needed on the victim; any remote peer in an RxRPC connection can send CHALLENGE packets, and unprivileged local users can create AF_RXRPC sockets, set MANAGE_RESPONSE, and call recvmsg() without special privileges.
UI:N - Exploitation does not require victim interaction beyond normal automated RxRPC/AFS client operation; recvmsg() is invoked automatically when OOB challenges are queued during connection security negotiation.
S:U - Impact is confined to kernel memory and locking on the affected host; it does not cross VM, container, or IOMMU security boundaries into a separate authority.
C:H - Double release_sock() corrupts socket lock ownership, allowing concurrent unsynchronized access to socket/call state and adjacent kernel heap objects, which can be leveraged for arbitrary kernel memory disclosure.
I:H - The corrupted socket lock permits overlapping recvmsg()/sendmsg() access to connection and skb state, enabling heap corruption and control-flow hijack primitives typical of kernel locking bugs.
A:H - The double unlock triggers lockdep warnings and can panic/oops the kernel or hang socket I/O when concurrent threads access the same RxRPC socket after ownership is incorrectly cleared.
CVSS 3.1