VulnerabilityPublished 4 Feb 2026Updated 19 Oct 2026

CVE-2026-23086: Linux kernel · vsock/virtio: cap TX credit to local buffer size

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in fef7110ae5617555c792a2bb4d27878d84583adf : update Linux kernel when convenient.

Data as of 26 Oct 2026, 14:18 UTC

Severity

Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS

0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

Exploitation: No evidence of active exploitation and no public proof of concept
Automatable: Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact: Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-06-10.

Patch

Available – fixed in fef7110ae5617555c792a2bb4d27878d84583adf, d9d5f222558b42f6277eafaaa6080966faf37676, c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce +2

Exploitation evidence

Disclosed: evidence found.
CVE published 4 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 06a8fc78367d070720af960dcecec917d3ae5f3b, < fef7110ae5617555c792a2bb4d27878d84583adf	Fixed in fef7110ae5617555c792a2bb4d27878d84583adf
LinuxLinux	Affected ≥ 06a8fc78367d070720af960dcecec917d3ae5f3b, < d9d5f222558b42f6277eafaaa6080966faf37676	Fixed in d9d5f222558b42f6277eafaaa6080966faf37676
LinuxLinux	Affected ≥ 06a8fc78367d070720af960dcecec917d3ae5f3b, < c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce	Fixed in c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce
LinuxLinux	Affected ≥ 06a8fc78367d070720af960dcecec917d3ae5f3b, < 84ef86aa7120449828d1e0ce438c499014839711	Fixed in 84ef86aa7120449828d1e0ce438c499014839711
LinuxLinux	Affected ≥ 06a8fc78367d070720af960dcecec917d3ae5f3b, < 8ee784fdf006cbe8739cfa093f54d326cbf54037	Fixed in 8ee784fdf006cbe8739cfa093f54d326cbf54037
LinuxLinux	Affected =4.8	Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: cap TX credit to local buffer size The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base. Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc. This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited. With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport. This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have. [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message]

CWE-400Uncontrolled Resource Consumption (opens in a new tab)
Class weaknessLikelihood of exploit: High
The product does not properly control the allocation and maintenance of a limited resource.
MITRE discourages mapping vulnerabilities to this broad entry; the root cause is usually a more specific weakness.
Architecture and Design
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place.
Architecture and Design
Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or; uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Architecture and Design
Ensure that protocols have specific limits of scale placed on them.
OWASP Cheat Sheets
File Upload (opens in a new tab)
OWASP ASVS 4.0.3
V12.1.1 (opens in a new tab)
Attack patterns
XML Ping of the Death (opens in a new tab)
Regular Expression Exponential Blowup (opens in a new tab)
Sustained Client Engagement (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

WeaknessesCWE-400

Technical details

References

Community reviews

Related threats