# CVE-2026-23069: integer underflow in the Linux kernel vsock/virtio transport

- **Published on:** 2026-02-04
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/cve-2026-23069-vsock-virtio-integer-underflow-kernel-linux

An integer underflow in vsock/virtio credit accounting can queue more data than the peer can handle. Affects a wide range of Linux kernel versions. CVSS 5.5.

---

The Linux kernel team has resolved **CVE-2026-23069**, an *integer underflow* vulnerability (CWE-191) in the **vsock/virtio** transport, specifically in the file `net/vmw_vsock/virtio_transport_common.c`. Although its severity is **medium (CVSS 3.1: 5.5)**, it is worth understanding because it affects a very wide range of versions and the communication subsystem between virtual machines and their host.

## What vsock/virtio is

`vsock` (virtio sockets) is the mechanism that lets a virtual machine and its hypervisor exchange data without going through the traditional network stack. To avoid overwhelming the receiver, the protocol uses a **credit** system: each end advertises how much buffer space it has available (`peer_buf_alloc`), and the other end only sends as much as fits.

## The vulnerability

The problem lies in the `virtio_transport_get_credit()` function, responsible for calculating how many credits remain available to send. According to the official kernel description:

> *"If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle."*

In other words: if the peer **shrinks the buffer size it had advertised** while there are still bytes in transit, the subtraction that computes the available credit can **underflow**. In unsigned arithmetic, subtracting more than you have does not yield a negative number but a **huge positive value**. As a result, the sender believes it has plenty of space and **queues more data than the receiver can handle**.

## Who is affected and severity

The CVSS vector is `AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`. This indicates:

- **Local vector (AV:L)**: requires local access; it is not directly exploitable from the Internet.
- **Low privileges (PR:L)** and no user interaction.
- Impact only on **availability (A:H)**: it does not compromise confidentiality or integrity. The realistic scenario is a **denial of service** or destabilization of the vsock channel, not code execution or data theft.

The affected versions span from **Linux 4.8** up to the maintained branches: **6.1.161, 6.6.121, 6.12.67** and **6.18.7**, plus some *release candidates* of the 6.19 series. It is mainly relevant in **virtualization** environments that use vsock (for example QEMU/KVM VMs or confidential workloads that rely on this channel).

## Mitigation and patch

The fix is simple and already integrated: instead of performing the subtraction directly, the code **reuses the existing `virtio_transport_has_space()` function**, which properly handles the boundary case and prevents the credit calculation from underflowing.

Recommendations:

1. **Update the kernel** to a version that includes the patch (6.1.162 or higher, 6.6.122+, 6.12.68+, 6.18.8+ or your distribution's equivalent).
2. On stable distributions (Debian, Ubuntu, RHEL and derivatives), **apply the kernel security updates** via the package manager; maintainers have already incorporated the backport.
3. If you manage a fleet of VMs, prioritize hosts that expose vsock to untrusted guests.

As a complementary best practice, it is advisable to strengthen virtual machine isolation and limit which processes can open vsock sockets. To dig deeper into system hardening, check our guide on [SELinux and AppArmor](/en/articles/selinux-and-apparmor).

## Source

- NVD - NIST: [CVE-2026-23069](https://nvd.nist.gov/vuln/detail/CVE-2026-23069)