Bug 2388933 (CVE-2025-38544)

Summary:	CVE-2025-38544 kernel: Linux kernel: Denial of Service in rxrpc due to prealloc collision
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	Keywords:	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 user can exploit this vulnerability by attempting to preallocate a call with an already in-use call ID within the AF_RXRPC subsystem. This can lead to a denial of service (DoS) due to assertions being triggered during error handling, making the system unavailable.	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 2025-08-16 12:02:22 UTC

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

rxrpc: Fix bug due to prealloc collision

When userspace is using AF_RXRPC to provide a server, it has to preallocate
incoming calls and assign to them call IDs that will be used to thread
related recvmsg() and sendmsg() together.  The preallocated call IDs will
automatically be attached to calls as they come in until the pool is empty.

To the kernel, the call IDs are just arbitrary numbers, but userspace can
use the call ID to hold a pointer to prepared structs.  In any case, the
user isn't permitted to create two calls with the same call ID (call IDs
become available again when the call ends) and EBADSLT should result from
sendmsg() if an attempt is made to preallocate a call with an in-use call
ID.

However, the cleanup in the error handling will trigger both assertions in
rxrpc_cleanup_call() because the call isn't marked complete and isn't
marked as having been released.

Fix this by setting the call state in rxrpc_service_prealloc_one() and then
marking it as being released before calling the cleanup function.

Comment 1 Jon Moroney 2025-08-18 15:59:54 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025081627-CVE-2025-38544-a2ab@gregkh/T