CVE-2026-98826 in Linux
Zusammenfassung
von VulDB • 18.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
rtc: ac100: Behebung eines Use-After-Free-Fehlers beim Clock-Anbieter bei einem fehlgeschlagenen Probe-Vorgang
ac100_rtc_register_clks() registriert den RTC-32k-Clock mit clk_hw_register_fixed_rate() und den Clock-Anbieter mit of_clk_add_hw_provider(). Keine der beiden Funktionen ist geräteseitig verwaltet (device managed), und beide werden nur aus ac100_rtc_remove() freigegeben. Der Treiber-Core ruft remove() nicht auf, wenn probe() fehlschlägt: really_probe() erreicht unterhalb des Aufrufs von device_remove() den Zustand probe_failed und geht direkt zur Freigabe der geräteseitig verwalteten Ressourcen über.
ac100_rtc_probe() endet mit
return devm_rtc_register_device(chip->rtc);
Wenn dies fehlschlägt, nachdem die Clocks registriert wurden, bleibt der Anbieter in der globalen Liste of_clk_providers zurück und hält chip->clk_data fest, das mit devm_kzalloc() allokiert wurde. Dieses wird freigegeben, während probe() abgewickelt (unwinds) wird. Ein späterer Lookup an diesem Device-Tree-Knoten liest dann aus freigemietetem Speicher in of_clk_hw_onecell_get(). Verbraucher, die genau dies tun, sind im Tree vorhanden: Die WiFi-Power-Sequenz-Knoten auf sun8i-a83t-bananapi-m3 und sun8i-a83t-cubietruck-plus verwenden <&ac100_rtc 1>, und die sun9i-a80-Boards leiten osc32k über <&ac100_rtc 0> weiter. Das Zeitfenster ist schmal, da devm_rtc_register_device() hier nur mit -ENOMEM fehlschlagen kann, aber der Anbieter bleibt hängen (dangling), wenn dies geschieht.
Der RTC-32k-Clock wird auf demselben Pfad geleakt. Da clk_core_lookup() eine globale Liste durchsucht, die nicht pro Gerät skopiert ist, lehnt __clk_register() den doppelten Namen mit -EEXIST ab; das Leck führt daher auch dazu, dass ein späterer Probe-Vorgang desselben Geräts fehlschlägt.
Der Fehlerpfad, der -EINVAL zurückgibt, wenn die ADDA-4M-Mutter-Clock nicht gefunden werden kann, leakt den RTC-32k-Clock auf dieselbe Weise. Zu diesem Zeitpunkt wurde kein Anbieter registriert, daher handelt es sich hierbei um ein Leck und nicht um einen Use-After-Free-Fehler.
Registrieren Sie beide mit devm_clk_hw_register_fixed_rate() und devm_of_clk_add_hw_provider(), damit sie freigegeben werden, wenn das Gerät verschwindet, sowohl bei einem fehlgeschlagenen Probe-Vorgang als auch beim Unbind. Devres gibt Ressourcen in umgekehrter Reihenfolge der Akquise frei; daher wird der Anbieter entfernt, bevor chip->clk_data freigegeben wird, und die clkout-Kinder werden nun vor ihrem Mutter-Clock statt danach deregistriert. ac100_rtc_unregister_clks() und der remove-Callback haben dann nichts mehr zu tun und werden entfernt.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.