Intel

CVE-2026-64232

Linux kernel (GCP) vulnerabilities

criticalEPSS 0.5 %

Beschreibung

Im Linux-Kernel wurde die folgende Schwachstelle behoben: block: Neuberechnung von nr_integrity_segments in blk_insert_cloned_request blk_insert_cloned_request() berechnet bereits nr_phys_segments neu gegenüber der untersten Warteschlange, da "die Warteschlangeneinstellungen bezüglich Segmentzählung sich von der ursprünglichen Warteschlange unterscheiden können." Das gleiche Argument gilt für Integritätssegmente: Die unterliegende Warteschlange eines gestapelten Treibers kann eine engere virt_boundary_mask, seg_boundary_mask oder max_segment_size als die oberste Warteschlange haben. In diesem Fall liefert blk_rq_count_integrity_sg() gegenüber der untersten Warteschlange eine andere Anzahl als das zwischengespeicherte rq->nr_integrity_segments, das von blk_rq_prep_clone() aus der Quellanforderung geerbt wurde. Wenn die zwischengespeicherte Anzahl niedriger ist als die tatsächliche Anzahl der untersten Warteschlange, löst blk_rq_map_integrity_sg() bei der Verteilung einen Fehler aus: BUG_ON(segments > rq->nr_integrity_segments); Die gleichen Familien gestapelter Setups, die die bestehende Neuberechnung von nr_phys_segments motivierten – insbesondere dm-multipath, das zu nvme-rdma führt – können dies verursachen. Spiegeln Sie die Behandlung von nr_phys_segments wider: Wenn die Anforderung Integrität trägt, berechnen Sie nr_integrity_segments neu gegenüber der untersten Warteschlange und lehnen Sie die Anforderung ab, wenn sie die max_integrity_segments der untersten Warteschlange überschreitet. blk_rq_count_integrity_sg() und queue_max_integrity_segments() sind beide bereits über <linux/blk-integrity.h> verfügbar, das von blk-mq.c eingeschlossen wird. Dies schließt eine latente Lücke im Stapelvertrag und bringt die Integritätssegment-Zählung in Einklang mit der bestehenden physikalischen Segment-Zählung.

Quelle: UBUNTU_USNUBUNTU_USNUBUNTU_USNUBUNTU_USNBSIBSI_CSAFCVELISTV5NVDCVEORG

Metriken

Severity
critical
Priority-Score
231.31
KEV-Status
—
Exploit-Reife
kein öffentlicher PoC bekannt
XIEM Effective CVSS
9.8
Quelle: nvd-v3
CVSS v3
9.8
CVSS v4
—
EPSS-Perzentil
38.4 %
Hoch — CVE rangiert über dem Median aller heute bewerteten CVEs (Rang ≥ 36 %).
EPSS-Score
0.5 %
Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Veröffentlicht
2026-09-07 09:05 UTC
CWE
—

Re-Analyse & Statuswechsel

Chronologie der NVD-Audit-Events für diese CVE — Reanalyses, CVSS-Updates, CPE-Diffs.

  1. New CVE Received2026-07-24 16:16 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Affected: Linux, Linux
    • Description: In the Linux kernel, the following vulnerability has been resolved: block: recompute nr_integrity_segments in blk_insert_cloned_request blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virt_boundary_mask, seg_boundary_mask, or max_segment_size than the top queue, in which case blk_rq_count_integrity_sg() against the bottom queue produces a different count than the cached rq->nr_integrity_segments inherited from the source request by blk_rq_prep_clone(). When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips BUG_ON(segments > rq->nr_integrity_segments); on dispatch. The same families of stacked setups that motivated the existing nr_phys_segments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this. Mirror the nr_phys_segments handling: when the request carries integrity, recompute nr_integrity_segments against the bottom queue and reject the request if it exceeds the bottom queue's max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes. This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
    • Reference: https://git.kernel.org/stable/c/0943f81e1b3176f27dbaf6db268fc69d8a94f0ba
    • Reference: https://git.kernel.org/stable/c/2c6e6a18a37b905cb584eb0dda3ae482162a81ca

Betroffene Betriebssysteme

  • linux

    redhat / enterprise_linux10.0

  • linux

    redhat / enterprise_linux7.0

  • linux

    redhat / enterprise_linux8.0

  • linux

    redhat / enterprise_linux9.0

  • linux

    ubuntu / linux-aws-6.8jammy

  • linux

    ubuntu / linux-azureresolute

  • linux

    ubuntu / linux-azuretrusty

  • linux

    ubuntu / linux-azurexenial

  • linux

    ubuntu / linux-azure-4.15bionic

  • linux

    ubuntu / linux-azure-5.4bionic

  • linux

    ubuntu / linux-azure-fdenoble

  • linux

    ubuntu / linux-azure-fderesolute

  • linux

    ubuntu / linux-azure-fde-6.8jammy

  • linux

    ubuntu / linux-azure-fipsbionic

  • linux

    ubuntu / linux-azure-fipsfocal

  • linux

    ubuntu / linux-azure-fipsnoble

  • linux

    ubuntu / linux-fipsjammy

  • linux

    ubuntu / linux-gcp-7.0noble

  • linux

    ubuntu / linux-gkejammy

  • linux

    ubuntu / linux-nvidia-tegranoble

  • linux

    ubuntu / linux-raspinoble

  • linux

    ubuntu / linux-raspi-realtimenoble

  • linux

    linux / linux_kernel2.6.12

  • linux

    linux / linux_kernel2.6.15

Quellen & Referenzen

Verknüpfte CVEs

1392 weitere CVEs anzeigen
IDCVE-2026-64232
Linux kernel (GCP) vulnerabilities — CVE-2026-64232 | NEOSEC Intel