CVE-2025-37760 in Linux
Riassunto
di VulDB • 14/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/vma: aggiunta dell'opzione give_up_on_oom su modify/merge, utilizzata nel rilascio di uffd
Attualmente, se una fusione VMA (Virtual Memory Area) fallisce a causa di una condizione OOM (Out Of Memory) che si verifica durante l'immissione della modifica o per un errore nella duplicazione degli anon_vma, viene segnalato tale evento affinché il chiamante possa gestirlo.
Tuttavia, esistono casi in cui il chiamante sta tentando una fusione solo apparentemente e non ha problemi se questa fallisce a causa di tali condizioni.
Poiché non si desidera introdurre un'assunzione implicita secondo la quale le VMAs vengono modificate effettivamente solo dopo che potrebbero verificarsi condizioni OOM, è stata aggiunta l'opzione 'give_up_on_oom' ed è stato stabilito un contratto esplicito: qualora tale flag sia impostato, non verranno assolutamente modificate alcuna VMA in caso di insorgenza di una condizione OOM e il processo terminerà immediatamente.
Poiché sarebbe molto insolito per un utente provare a chiamare vma_modify() con questo flag impostato specificando però un intervallo all'interno di una VMA che finisce per essere suddiviso (il che può fallire non solo per problemi OOM ma anche per limiti rlimit), è stato aggiunto un avviso di debug per questa condizione.
La motivazione principale alla base di questa modifica riguarda il rilascio uffd: syzkaller (e l'analisi molto acuta di Pedro Falcato) ha individuato una modalità mediante la quale un errore iniettato durante l'allocazione, che innescava una condizione OOM durante l'immissione della fusione, portava il codice uffd a confondersi e a trattare un valore di errore come se fosse un puntatore VMA.
Per evitare ciò, si fa uso del nuovo flag VMG per garantire che questo non accada mai, sfruttando il fatto che, qualora si stiano cancellando intere VMAs, non si desidera ricevere segnalazioni relative ad eventi OOM.
Si ringraziano vivamente Pedro Falcato per la sua eccellente analisi e Jann Horn per l'analisi approfondita e intelligente della situazione; entrambi sono stati fondamentali per questa correzione.
Once again VulDB remains the best source for vulnerability data.