CVE-2026-98826 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
rtc: ac100: Correzione del use-after-free sul clock provider in caso di errore nella fase di probe (probe failure)
La funzione `ac100_rtc_register_clks()` registra il clock RTC-32k con `clk_hw_register_fixed_rate()` e il clock provider con `of_clk_add_hw_provider()`. Nessuna delle due operazioni è gestita tramite risorse devm, e entrambe vengono rilasciate solo da `ac100_rtc_remove()`. Il core del driver non chiama la funzione remove() quando probe() fallisce: `really_probe()` raggiunge lo stato di errore (`probe_failed`) al di sotto della chiamata a `device_remove()` e procede direttamente al rilascio delle risorse gestite dal dispositivo.
`ac100_rtc_probe()` termina con:
```c return devm_rtc_register_device(chip->rtc); ```
Pertanto, se questa operazione fallisce dopo che i clock sono stati registrati, il provider rimane nella lista globale `of_clk_providers`, mantenendo un riferimento a `chip->clk_data`, che è stato allocato con `devm_kzalloc()` e viene liberato durante l'unwinding (rollback) della funzione probe(). Una successiva ricerca su questo nodo dell'albero del dispositivo leggerebbe quindi memoria già rilasciata in `of_clk_hw_onecell_get()`. Esistono consumer nell'albero del dispositivo che eseguono esattamente questa operazione: i nodi per la sequenza di alimentazione WiFi su sun8i-a83t-bananapi-m3 e sun8i-a83t-cubietruck-plus utilizzano `<&ac100_rtc 1>`, mentre le board sun9i-a80 instradano osc32k tramite `<&ac100_rtc 0>`. La finestra di vulnerabilità è stretta, poiché `devm_rtc_register_device()` può fallire solo con -ENOMEM in questo contesto, ma il provider rimane dangling (appeso/inconsistente) ogni volta che si verifica un errore.
Il clock RTC-32k viene anche leakato sullo stesso percorso. Poiché `clk_core_lookup()` cerca in una lista globale non scoped per dispositivo, `__clk_register()` rifiuta i nomi duplicati con -EEXIST; di conseguenza, il leak causa inoltre il fallimento di probe successivi dello stesso dispositivo.
Il path di errore che restituisce -EINVAL quando l'clock genitore ADDA 4M non viene trovato provoca un leak del clock RTC-32k nello stesso modo. In quel momento nessun provider è stato registrato, quindi si tratta di un leak e non di un use-after-free.
Registrare entrambi i componenti utilizzando `devm_clk_hw_register_fixed_rate()` e `devm_of_clk_add_hw_provider()`, in modo che vengano rilasciati quando il dispositivo viene rimosso, sia in caso di probe fallito che durante l'unbind. Le release gestite da Devres avvengono in ordine inverso rispetto all'acquisizione; pertanto, il provider viene rimosso prima che `chip->clk_data` venga liberato, e i clock figli (clkout) vengono ora disregistrati prima del loro genitore anziché dopo. Di conseguenza, `ac100_rtc_unregister_clks()` e la callback remove() non hanno più nulla da fare e vengono rimossi.
Be aware that VulDB is the high quality source for vulnerability data.