CVE-2026-23086 (GCVE-0-2026-23086)
Vulnerability from cvelistv5 – Published: 2026-02-04 16:08 – Updated: 2026-02-06 16:33
VLAI?
Title
vsock/virtio: cap TX credit to local buffer size
Summary
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]
Severity ?
No CVSS data available.
Assigner
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Affected:
06a8fc78367d070720af960dcecec917d3ae5f3b , < fef7110ae5617555c792a2bb4d27878d84583adf
(git)
Affected: 06a8fc78367d070720af960dcecec917d3ae5f3b , < d9d5f222558b42f6277eafaaa6080966faf37676 (git) Affected: 06a8fc78367d070720af960dcecec917d3ae5f3b , < c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce (git) Affected: 06a8fc78367d070720af960dcecec917d3ae5f3b , < 84ef86aa7120449828d1e0ce438c499014839711 (git) Affected: 06a8fc78367d070720af960dcecec917d3ae5f3b , < 8ee784fdf006cbe8739cfa093f54d326cbf54037 (git) |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/vmw_vsock/virtio_transport_common.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "fef7110ae5617555c792a2bb4d27878d84583adf",
"status": "affected",
"version": "06a8fc78367d070720af960dcecec917d3ae5f3b",
"versionType": "git"
},
{
"lessThan": "d9d5f222558b42f6277eafaaa6080966faf37676",
"status": "affected",
"version": "06a8fc78367d070720af960dcecec917d3ae5f3b",
"versionType": "git"
},
{
"lessThan": "c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce",
"status": "affected",
"version": "06a8fc78367d070720af960dcecec917d3ae5f3b",
"versionType": "git"
},
{
"lessThan": "84ef86aa7120449828d1e0ce438c499014839711",
"status": "affected",
"version": "06a8fc78367d070720af960dcecec917d3ae5f3b",
"versionType": "git"
},
{
"lessThan": "8ee784fdf006cbe8739cfa093f54d326cbf54037",
"status": "affected",
"version": "06a8fc78367d070720af960dcecec917d3ae5f3b",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/vmw_vsock/virtio_transport_common.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.8"
},
{
"lessThan": "4.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.162",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.122",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.68",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19-rc7",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.162",
"versionStartIncluding": "4.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.122",
"versionStartIncluding": "4.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.68",
"versionStartIncluding": "4.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.8",
"versionStartIncluding": "4.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19-rc7",
"versionStartIncluding": "4.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: cap TX credit to local buffer size\n\nThe virtio transports derives its TX credit directly from peer_buf_alloc,\nwhich is set from the remote endpoint\u0027s SO_VM_SOCKETS_BUFFER_SIZE value.\n\nOn the host side this means that the amount of data we are willing to\nqueue for a connection is scaled by a guest-chosen buffer size, rather\nthan the host\u0027s own vsock configuration. A malicious guest can advertise\na large buffer and read slowly, causing the host to allocate a\ncorrespondingly large amount of sk_buff memory.\nThe same thing would happen in the guest with a malicious host, since\nvirtio transports share the same code base.\n\nIntroduce a small helper, virtio_transport_tx_buf_size(), that\nreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consume\npeer_buf_alloc.\n\nThis ensures the effective TX window is bounded by both the peer\u0027s\nadvertised buffer and our own buf_alloc (already clamped to\nbuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer\ncannot force the other to queue more data than allowed by its own\nvsock settings.\n\nOn an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with\n32 guest vsock connections advertising 2 GiB each and reading slowly\ndrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only\nrecovered after killing the QEMU process. That said, if QEMU memory is\nlimited with cgroups, the maximum memory used will be limited.\n\nWith this patch applied:\n\n Before:\n MemFree: ~61.6 GiB\n Slab: ~142 MiB\n SUnreclaim: ~117 MiB\n\n After 32 high-credit connections:\n MemFree: ~61.5 GiB\n Slab: ~178 MiB\n SUnreclaim: ~152 MiB\n\nOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest\nremains responsive.\n\nCompatibility with non-virtio transports:\n\n - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per\n socket based on the local vsk-\u003ebuffer_* values; the remote side\n cannot enlarge those queues beyond what the local endpoint\n configured.\n\n - Hyper-V\u0027s vsock transport uses fixed-size VMBus ring buffers and\n an MTU bound; there is no peer-controlled credit field comparable\n to peer_buf_alloc, and the remote endpoint cannot drive in-flight\n kernel memory above those ring sizes.\n\n - The loopback path reuses virtio_transport_common.c, so it\n naturally follows the same semantics as the virtio transport.\n\nThis change is limited to virtio_transport_common.c and thus affects\nvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the\n\"remote window intersected with local policy\" behaviour that VMCI and\nHyper-V already effectively have.\n\n[Stefano: small adjustments after changing the previous patch]\n[Stefano: tweak the commit message]"
}
],
"providerMetadata": {
"dateUpdated": "2026-02-06T16:33:07.362Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/fef7110ae5617555c792a2bb4d27878d84583adf"
},
{
"url": "https://git.kernel.org/stable/c/d9d5f222558b42f6277eafaaa6080966faf37676"
},
{
"url": "https://git.kernel.org/stable/c/c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce"
},
{
"url": "https://git.kernel.org/stable/c/84ef86aa7120449828d1e0ce438c499014839711"
},
{
"url": "https://git.kernel.org/stable/c/8ee784fdf006cbe8739cfa093f54d326cbf54037"
}
],
"title": "vsock/virtio: cap TX credit to local buffer size",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23086",
"datePublished": "2026-02-04T16:08:10.047Z",
"dateReserved": "2026-01-13T15:37:45.961Z",
"dateUpdated": "2026-02-06T16:33:07.362Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2026-23086\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-02-04T17:16:19.467\",\"lastModified\":\"2026-02-06T17:16:24.170\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nvsock/virtio: cap TX credit to local buffer size\\n\\nThe virtio transports derives its TX credit directly from peer_buf_alloc,\\nwhich is set from the remote endpoint\u0027s SO_VM_SOCKETS_BUFFER_SIZE value.\\n\\nOn the host side this means that the amount of data we are willing to\\nqueue for a connection is scaled by a guest-chosen buffer size, rather\\nthan the host\u0027s own vsock configuration. A malicious guest can advertise\\na large buffer and read slowly, causing the host to allocate a\\ncorrespondingly large amount of sk_buff memory.\\nThe same thing would happen in the guest with a malicious host, since\\nvirtio transports share the same code base.\\n\\nIntroduce a small helper, virtio_transport_tx_buf_size(), that\\nreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consume\\npeer_buf_alloc.\\n\\nThis ensures the effective TX window is bounded by both the peer\u0027s\\nadvertised buffer and our own buf_alloc (already clamped to\\nbuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer\\ncannot force the other to queue more data than allowed by its own\\nvsock settings.\\n\\nOn an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with\\n32 guest vsock connections advertising 2 GiB each and reading slowly\\ndrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only\\nrecovered after killing the QEMU process. That said, if QEMU memory is\\nlimited with cgroups, the maximum memory used will be limited.\\n\\nWith this patch applied:\\n\\n Before:\\n MemFree: ~61.6 GiB\\n Slab: ~142 MiB\\n SUnreclaim: ~117 MiB\\n\\n After 32 high-credit connections:\\n MemFree: ~61.5 GiB\\n Slab: ~178 MiB\\n SUnreclaim: ~152 MiB\\n\\nOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest\\nremains responsive.\\n\\nCompatibility with non-virtio transports:\\n\\n - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per\\n socket based on the local vsk-\u003ebuffer_* values; the remote side\\n cannot enlarge those queues beyond what the local endpoint\\n configured.\\n\\n - Hyper-V\u0027s vsock transport uses fixed-size VMBus ring buffers and\\n an MTU bound; there is no peer-controlled credit field comparable\\n to peer_buf_alloc, and the remote endpoint cannot drive in-flight\\n kernel memory above those ring sizes.\\n\\n - The loopback path reuses virtio_transport_common.c, so it\\n naturally follows the same semantics as the virtio transport.\\n\\nThis change is limited to virtio_transport_common.c and thus affects\\nvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the\\n\\\"remote window intersected with local policy\\\" behaviour that VMCI and\\nHyper-V already effectively have.\\n\\n[Stefano: small adjustments after changing the previous patch]\\n[Stefano: tweak the commit message]\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/84ef86aa7120449828d1e0ce438c499014839711\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/8ee784fdf006cbe8739cfa093f54d326cbf54037\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d9d5f222558b42f6277eafaaa6080966faf37676\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/fef7110ae5617555c792a2bb4d27878d84583adf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…