CVE-2026-23086 (GCVE-0-2026-23086)

Vulnerability from cvelistv5 – Published: 2026-02-04 16:08 – Updated: 2026-02-09 08:38
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)
Create a notification for this product.
    Linux Linux Affected: 4.8
Unaffected: 0 , < 4.8 (semver)
Unaffected: 6.1.162 , ≤ 6.1.* (semver)
Unaffected: 6.6.122 , ≤ 6.6.* (semver)
Unaffected: 6.12.68 , ≤ 6.12.* (semver)
Unaffected: 6.18.8 , ≤ 6.18.* (semver)
Unaffected: 6.19 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "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",
              "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",
                  "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-09T08:38:26.222Z",
        "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-09T08:38:26.222Z",
    "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\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.



Detection rules are retrieved from Rulezet.