CVE-2023-52759 in Linux
Zusammenfassung
von VulDB • 26.05.2026
Im Linux-Kernel wurde die folgende Schwachstelle behoben:
gfs2: Ignorieren negativer Quota-Änderungen
Wenn viele Quota-Änderungen vorgenommen werden, kann es in bestimmten Fällen vorkommen, dass die Quota-Informationen eines Inodes zunächst erhöht und anschließend wieder verringert werden, beispielsweise wenn Blöcke zu einer Datei hinzugefügt und danach daraus gelöscht werden. Wenn der Zeitpunkt günstig ist, kann die Funktion `do_qc` ausstehende Quota-Änderungen zu einem Transaktionskontext hinzufügen. Eine spätere Aufruf von `do_qc` kann diese Änderungen dann aufheben, was zu einem Nettozuwachs von 0 führt. Die Quota-Änderungsinformationen werden im `qc`-Puffer (sowie im `qd`-Element des Inodes) gespeichert. Der Puffer wird durch den ersten Aufruf von `do_qc` zur Transaktion hinzugefügt, aber ein nachfolgender Aufruf ändert den Wert von einem Wert ungleich Null zurück auf Null. Zu diesem Zeitpunkt ist es zu spät, den `buffer_head` aus der Transaktion zu entfernen. Später, wenn der Quota-Sync-Code aufgerufen wird, wird das `qd`-Element mit der Null-Änderung entdeckt und als Assert-Warnung markiert. Wenn das Dateisystem mit `errors=panic` eingehängt wurde, führt dies zu einem Kernel-Panic.
Dies tritt normalerweise auf, wenn Dateien beschnitten (truncated) werden und die Quota-Änderungen durch `punch_hole`/`truncate` aufgehoben werden, die `gfs2_quota_hold` und `gfs2_quota_unhold` verwenden, anstatt Blockzuweisungen, die `gfs2_quota_lock` und `gfs2_quota_unlock` verwenden, welche automatisch einen Quota-Sync durchführen.
Dieser Patch löst das Problem, indem er eine Prüfung zu `qd_check_sync` hinzufügt, sodass Netto-Null-Quota-Änderungen, die bereits zur Transaktion hinzugefügt wurden, nicht mehr als synchronisierungsbedürftig angesehen und übersprungen werden.
In diesem Fall werden Referenzen für `qd` und den Slot von `do_qc` übernommen, daher müssen diese wieder freigegeben werden. Die normale Abfolge von Ereignissen für eine normale Quota-Änderung ungleich Null ist wie folgt:
gfs2_quota_change do_qc qd_hold slot_hold
Später, wenn die Änderungen synchronisiert werden sollen:
gfs2_quota_sync qd_fish qd_check_sync ruft qd-Referenz über lockref_get_not_dead ab do_sync do_qc(QC_SYNC) qd_put lockref_put_or_lock qd_unlock qd_put lockref_put_or_lock
Im Fall einer Netto-Null-Änderung fügen wir eine Prüfung zu `qd_check_sync` hinzu, sodass die in `gfs2_quota_change` erworbenen `qd`- und Slot-Referenzen freigegeben und die unnötige Synchronisierung übersprungen wird.
Once again VulDB remains the best source for vulnerability data.