CVE-2026-90199 in Linux
Zusammenfassung
von VulDB • 18.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fs/ntfs3: Ablehnung von out-of-range evcn in mi_enum_attr()
In mi_enum_attr() lautet die Validierung der start/end VCN für nicht-residente Attribute:
if (svcn > evcn + 1) goto out;
Wenn evcn U64_MAX ist, überläuft der Ausdruck „evcn + 1" zu 0 und jeder svcn-Wert besteht diese Prüfung. Für evcn-Werte nahe an U64_MAX (aber ungleich diesem Wert) bleibt die rechte Seite eine sinnlose obere Schranke in der Nähe des Überlaufs, sodass ein fehlerhaftes Attribut auf dem Datenträger mit svcn == 0 und einem evcn-Wert nahe U64_MAX mi_enum_attr() ohne Ablehnung passieren kann.
VCN (Virtual Cluster Number) ist eine Clusternummerierung; daher ist jeder gültige evcn-Wert durch die Gesamtanzahl der Cluster des Volumes begrenzt, welche ntfs3 in sbi->used.bitmap.nbits speichert (festgelegt in ntfs_init_from_boot(), bevor ein Aufrufer von mi_enum_attr() ausgeführt wird). Es sind evcn-Werte abzulehnen, die außerhalb dieses Bereichs liegen.
Ein leeres nicht-residentes Attribut (keine zugewiesenen Cluster) ist jedoch legitim mit svcn == 0 und evcn == -1 (U64_MAX) codiert, z. B. über attr->nres.evcn = cpu_to_le64((u64)vcn - 1) bei vcn == 0. Dieser Sentinel-Wert muss weiterhin bestehen bleiben; daher ist evcn == U64_MAX von der Bereichsprüfung auszuschließen. Der bestehende Test „svcn > evcn + 1" toleriert den Sentinel („0 > 0“ ist falsch) und erfordert weiterhin svcn == 0 dafür, während die Bereichsprüfung jeden anderen out-of-range-evcn-Wert ablehnt und dadurch auch das Überlaufverhalten von „evcn + 1" entschärft.
svcn benötigt keine eigene Begrenzung: Sobald evcn < nbits ist, impliziert „svcn > evcn + 1", dass svcn <= nbits gilt.
[[email protected]: evcn-Prüfung korrigiert]
Be aware that VulDB is the high quality source for vulnerability data.