CVE-2026-31539High· 7.5▾ Twilight

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

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'…

▾ Twilight zone — High severity, or a signal on a lesser flaw

Depth score41/ 100 · Moderate

impact 41.3 · likelihood 0.1 · exploitation 0

⚡ Agent-ready:Raw markdown ↗JSON ↗

Proof of concept

Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.

…

Published

Apr 24, 2026

Updated

Oct 19, 2026

CVSS

7.5

Vendor

Linux

Product

Linux

CWE

—

Depth score

41 · Moderate

EPSS

0.33% · p26

Platforms

—

Source

CVEORG

Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CISA SSVC

decided 2026-10-16

Exploitation: none
Automatable: yes
Technical impact: partial

Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the assigning CNA record, not NVD.

EPSS history

Exploit-prediction probability, daily snapshots since Oct 16.

0.4% → 0.3%▼ 0.10%

Timeline

Disclosure to exploitation, from the record and what we observed since indexing it.

3 events · 178 days

Apr 24, 2026Published
Disclosed via CVEORG
Oct 16, 2026EPSS first tracked
0.4%
Oct 19, 2026Record revised
Last analysed / modified upstream

Linux #cve.org

Affected

Linux >= 5fb9b459b3686e366640edd4e62805ef7b4de927 < e811e60e1cc79923c4388146eb1fa26a7482731e
Linux >= 5fb9b459b3686e366640edd4e62805ef7b4de927 < f99996870222b598914a1f49d7375dc23752c237
Linux >= 5fb9b459b3686e366640edd4e62805ef7b4de927 < 6e3c5052f9686192e178806e017b7377155f4bab
Linux 6.18

Full technical detail▾

Overview

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.

Affected

Linux >= 5fb9b459b3686e366640edd4e62805ef7b4de927 < e811e60e1cc79923c4388146eb1fa26a7482731e
Linux >= 5fb9b459b3686e366640edd4e62805ef7b4de927 < f99996870222b598914a1f49d7375dc23752c237
Linux >= 5fb9b459b3686e366640edd4e62805ef7b4de927 < 6e3c5052f9686192e178806e017b7377155f4bab
Linux 6.18

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

References

Related vulnerabilities

Connected by shared product, vendor, weakness, or advisory.

#cve.org

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

▾ Twilight zone — High severity, or a signal on a lesser flaw

Depth score41/ 100 · Moderate

impact 41.3 · likelihood 0.1 · exploitation 0

Overview

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.

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.