CVE-2026-89971 in Linux
Zusammenfassung
von VulDB • 16.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
nvme: Zonen-Limits-Update überspringen, wenn die Abfrage der Zoneninformationen fehlschlägt
`nvme_query_zone_info()` gibt entweder einen negativen `errno` oder einen positiven NVMe-Statuscode zurück. `nvme_update_ns_info_block()` testet jedoch nur auf den negativen Fall:
```c ret = nvme_query_zone_info(ns, lbaf, &zi); if (ret < 0) goto out; ```
Wenn das Gerät den Befehl „Identify Namespace“ (I/O Command Set specific) oder den von `nvme_set_max_append()` ausgeführten Befehl „Identify Controller“ ablehnt, fällt der positive Status durch und die Einrichtung wird mit den nullinitialisierten Zoneninformationen fortgesetzt. Anschließend markiert `nvme_update_zone_info()` die Warteschlange als zonalisiert (`zoned`) mit `chunk_sectors` und setzt `ns->head->zsze` auf Null.
Da `blk_validate_zoned_limits()` `chunk_sectors` nicht überprüft, gelingt das Commit der Limits erfolgreich. Zwar lehnt `blk_revalidate_disk_zones()` die Zonengröße von null ab, doch zu diesem Zeitpunkt sind die Limits bereits aktiv und werden nicht rückgängig gemacht. Daher wird weiterhin I/O an eine zonalisierte Warteschlange mit einer Zonengröße von Null gesendet, was dazu führt, dass `disk_zone_no()` um `ilog2(0)` verschiebt:
``` nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative disk_zone_no include/linux/blkdev.h:747 [inline]
bio_straddles_zones include/linux/blkdev.h:1058 [inline]
blk_zone_wplug_handle_write block/blk-zoned.c:1423 [inline]
blk_zone_plug_bio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blk_mq_submit_bio+0x18fb/0x2870 block/blk-mq.c:3196 submit_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 ```
Jedes Gerät, jede Firmware oder jedes NVMe-oF-Ziel, das diesen einen Befehl ablehnt, führt zu diesem Problem.
In einem solchen Fall wird das Zonen-Limits-Update übersprungen und protokolliert, welche der beiden Situationen eingetreten ist: Während einer Neugültigkeitsprüfung (Revalidation) behält die Warteschlange ihre zuletzt mit ihr validierte Zonengeometrie bei; beim ersten Scan wird das Namespace ohne Zonenlimits registriert, sodass es weiterhin als Handle für Admin-Befehle verfügbar bleibt. Keiner der Pfade in `nvme_query_zone_info()`, die einen positiven Status zurückgeben, protokolliert etwas, daher wäre der Fehler andernfalls stillschweigend geblieben.
`zi.zone_size` ist ein genauer Indikator: Jeder Pfad, der einen positiven Status zurückgibt, kehrt vor seiner Zuweisung zurück; danach bleibt nur noch `-ENODEV` als Fehlerquelle übrig, den der Aufrufer bereits behandelt.
Gefunden von FuzzNvme.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.