CVE-2026-68090 in Linux
Zusammenfassung
von VulDB • 10.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
debugobjects: Race-Bedingung bei gleichzeitiger Deaktivierung von OOM (Out-of-Memory) beheben
syzbot meldete ein rätselhaftes Kernel-Panic/Warning-Splat:
WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20
stub_timer() wird als Timer-Rückruffunktion (Callback) in hrtimer_fixup_assert_init() installiert, die aufgerufen wird, wenn debug_object_assert_init() kein Schattenobjekt (Shadow Object) finden kann. In diesem Fall gibt debug objects eine Warnung aus, bevor der Fixup ausgeführt wird.
Obwohl das bereitgestellte Konsolenprotokoll diese Warnung nicht enthält und stattdessen einige Sekunden vor dem Splat Folgendes zeigt:
ODEBUG: Out of memory. ODEBUG disabled (Speicher erschöpft. ODEBUG deaktiviert)
Das Objekt wurde in debug_object_assert_init() gesucht, aber der Lookup schlug aufgrund einer gleichzeitigen Speichererschöpfungssituation fehl, die debug objects deaktivierte und die Schattenobjekte freigab:
debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) {
// Out of memory (Speicher erschöpft) debug_objects_enabled = false; free_objects(); obj = lookup_or_alloc();
// Der Lookup schlug fehl, weil die andere Seite // die Objekte entfernt hat. Daher wird hier ein // Fehlercode zurückgegeben, da das betreffende Objekt // nicht statisch initialisiert ist
if (!IS_ERR_OR_NULL(obj)) return; if (!obj) {
debug_oom(); return; }
print(...) if (!debug_objects_enabled) return;
fixup(...)
Das debug object Splat wird übersprungen, da debug_objects_enabled falsch (false) ist, aber der Fixup-Callback wird bedingungslos aufgerufen, was den Timer funktionsunfähig macht.
Dies ist nur ein Problem in debug_object_assert_init() und debug_object_activate(), da beide statisch initialisierte Objekte behandeln müssen und daher den Rückgabewert eines Fehlerzeigers (error pointer) gracefully handhaben müssen. An allen anderen Stellen wird lediglich der Fall Gefunden/Nicht-Gefunden behandelt, und die NULL-Zeiger-Rückgabe ist ein Signal für OOM (Out-of-Memory). Andernfalls erhalten sie ein gültiges Schattenobjekt.
Schließen Sie diese Lücke, indem Sie prüfen, ob debug objects noch aktiviert sind, bevor Sie in diesen beiden Fällen die print- und fixup-Funktion aufrufen.
Once again VulDB remains the best source for vulnerability data.