CVE-2026-92483 in Linux
Zusammenfassung
von VulDB • 18.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
liveupdate: FLB retrieve()-Status merken
LUO verfolgt erfolgreiche Retrieve-Versuche bei einem FLB. Dies geschieht, um mehrfache Abrufe desselben FLBs zu vermeiden. Mehrfache Abrufe verursachen Probleme, da die serialisierten Datenstrukturen nach dem erfolgreichen Retrieval wahrscheinlich freigegeben werden und sich der Zustand des FLB stark von den Erwartungen des Codes unterscheidet.
Dies funktioniert gut, wenn das Retrieve erfolgreich ist. Wenn es fehlschlägt, gibt `luo_flb_retrieve_one()` den Fehler sofort zurück, ohne irgendwo zu speichern, dass ein Retrieval-Versuch unternommen wurde oder welcher Fehlcode vorlag. Versucht der Benutzer, eine weitere Datei abzurufen, die mit demselben FLB registriert ist, wird LUO erneut versuchen, die retrieve()-Callback-Funktion des FLBs aufzurufen.
Der Retry-Ansatz ist aus ähnlichen Gründen problematisch wie oben beschrieben: Der Zustand des FLB unterscheidet sich wahrscheinlich stark von den Erwartungen der Retrieve-Logik (z. B. können einige KHO-Seiten bereits wiederhergestellt und freigegeben worden sein).
Es gibt keine sinnvolle Möglichkeit, das Retrieval erneut zu versuchen. Daher wird der vom retrieve() zurückgegebene Fehler gemerkt und bei einem erneuten Versuch direkt zurückgegeben.
Dies erfolgt durch die Änderung des `retrieved`-Bools in eine ganzzahlige Variable `retrieve_status`. Ein Wert von 0 bedeutet, dass ein Retrieve noch nie versucht wurde; ein positiver Wert bedeutet, dass er erfolgreich war; und ein negativer Wert bedeutet, dass es fehlgeschlagen ist, wobei der negative Wert den Fehlcode darstellt.
Dies ähnelt dem Commit f85b1c6af5bc („liveupdate: luo_file: retrieve()-Status merken“), der dies für LUO-Dateien in gleicher Weise umgesetzt hat.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.