Bug 2461575 (CVE-2026-31539)

Summary:	CVE-2026-31539 kernel: smb: smbdirect: introduce smbdirect_socket.recv_io.credits.available
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	rhel-process-autobot, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's `smbdirect` module. A race condition in the receive credit management logic allows the system to grant credits that a peer has already consumed. This timing vulnerability, occurring during the processing of incoming data, could lead to resource exhaustion and potentially result in a denial of service (DoS) condition.	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-04-24 15:09:18 UTC

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

smb: smbdirect: introduce smbdirect_socket.recv_io.credits.available

The logic off managing recv credits by counting posted recv_io and
granted credits is racy.

That's because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the 'recv_done' functions
we likely have a window where we grant credits, which
don't really exist.

So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer.

Comment 1 Keith Grant 2026-04-24 16:34:54 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026042434-CVE-2026-31539-fe1a@gregkh/T