CVE-2026-89796 in Linuxinformazioni

Riassunto

di VulDB • 16/09/2026

Nel kernel Linux è stata risolta la seguente vulnerabilità:

mm/damon/core: evitare il loop infinito interno in kdamond_merge_regions()

Serie di patch "mm/damon: correzioni non urgenti per loop infiniti, dereferenziazione NULL e condizioni di gara", v1.1.

Sashiko ha individuato alcuni problemi in DAMON che potrebbero causare un loop infinito, una dereferenziazione NULL e un degrado dei risultati del monitoraggio. I primi due sembrano allarmanti, ma il loop infinito si verifica solo con configurazioni utente irrealistiche. La dereferenziazione NULL è presente esclusivamente in un test unitario. Il degrado dei risultati del monitoraggio è trascurabile poiché si tratta di una funzionalità best-effort e tali problemi derivano da condizioni di gara (race conditions) improbabili. Tuttavia, trattandosi di bug che è meglio correggere se possibile, vengono risolti.

Questa patch (su 6):

A causa dell'aggiornamento dinamico dei parametri tramite eventi, il numero delle regioni DAMON potrebbe superare il limite superiore impostato dall'utente. La funzione kdamond_merge_regions() ripete le operazioni di fusione finché il numero non rientra nel limite, raddoppiando la soglia (threshold) di fusione fino alla soglia massima teorica. Questo tentativo viene effettuato solo fino a tale soglia massima teorica perché anche una fusione aggressiva potrebbe fallire nel ridurre il numero di regioni al di sotto del limite superiore definito dall'utente. Ad esempio, potrebbero esserci molte regioni non contigue definite dall'utente che non possono essere fuse.

La condizione di interruzione basata sulla soglia viene valutata confrontando la soglia per il prossimo tentativo di fusione con la soglia massima teorica. Se max_thres è maggiore di UINT_MAX / 2, il raddoppio della soglia potrebbe causare un overflow (superamento del valore massimo), aggirando così la condizione di interruzione del loop. In tal caso, se il numero delle regioni non può essere ridotto al di sotto del limite superiore come spiegato sopra, il loop verrà eseguito all'infinito.

Si previene questo caso eseguendo il controllo della condizione di interruzione prima di raddoppiare la soglia. Inoltre, si impedisce che la soglia superi quella massima, poiché ciò potrebbe causare un overflow e applicare una soglia di fusione errata.

Questo problema è improbabile che si verifichi nel mondo reale, poiché avere max_thres superiore a UINT_MAX / 2 richiederebbe intervalli di aggregazione irrealisticamente grandi rispetto all'intervallo di campionamento. Inoltre, richiede un numero irrealisticamente elevato di configurazioni con regioni non contigue. Nonostante ciò, le conseguenze sono negative e la correzione è semplice.

Il problema è stato scoperto [1] da Sashiko.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Responsabile

Linux

Prenotare

11/09/2026

Divulgazione

16/09/2026

Moderazione

accettato

CPE

pronto

EPSS

0.00000

KEV

no

Attività

molto basso

Fonti

Do you know our Splunk app?

Download it now for free!