CVE-2026-63799 in Linux
Riassunto
di VulDB • 20/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
sched/mmcid: Correzione della scrittura fuori dai limiti (OOB) di clear_bit quando il CID è impostato su MM_CID_UNSET nel percorso di fixup
In mm_cid_fixup_cpus_to_tasks(), quando rq->curr possiede il target mm e mm_cid.active è impostata, il CID viene verificato tramite cid_in_transit() prima di impostare il bit di transizione. In modalità per-CPU, un task appena creato (fork) o eseguito (exec) può trovarsi in esecuzione con mm_cid.cid == MM_CID_UNSET poiché i CIDs vengono assegnati in modo lazy durante lo schedule-in. Con la funzione cid_in_transit(), il controllo passa anche per MM_CID_UNSET (nessun bit di transizione), convertendolo in MM_CID_UNSET | MM_CID_TRANSIT e memorizzandolo nuovamente; successivamente, mm_cid_schedout() alimenta questo valore a clear_bit() utilizzando MM_CID_UNSET come numero di bit, innescando una scrittura fuori dai limiti.
Sintomi: si tratta di una vera corruzione della memoria, ma di una scrittura fuori dai limiti limitata (bounded), non arbitraria. MM_CID_UNSET è il sentinella fissa BIT(31); pertanto, una volta che il valore errato raggiunge mm_cid_schedout(), la funzione cid_from_transit_cid() rimuove i bit di transizione lasciando solo MM_CID_UNSET, il quale fallisce il test di convergenza "cid < max_cids" e cade in mm_drop_cid() -> clear_bit(MM_CID_UNSET, mm_cidmask(mm)). Il bitmap dei CID è incorporato nell'oggetto slab di mm_struct (dopo cpu_bitmap e mm_cpus_allowed) ed ha una larghezza pari a num_possible_cpus() bit; cancellare il bit 31 costituisce quindi un chiaro caso deterministico di scrittura fuori dai limiti (OOB bit-clear) con uno spostamento fisso di 2^31 / 8 == 256 MiB oltre la base del bitmap. L'indirizzo non è influenzabile dall'attaccante (sentinella fissa -> offset fisso) e l'operazione cancella un solo bit; ciò che si trova a ulteriori 256 MiB lungo la mappatura diretta dipende da quale oggetto kernel risiede in quel punto, quindi viene corrotto un singolo bit di memoria del kernel imprevedibile: non si tratta di una scrittura su indirizzo o valore arbitrario.
La vulnerabilità si attiva solo nella modalità CID per-CPU, quando una CPU sta eseguendo un task attivo del target mm il cui cid è ancora MM_CID_UNSET — la finestra tra fork()/execve() e il successivo schedule-in che assegna al task un vero CID — e viene eseguito un fixup da per-CPU a per-task (il fallback di modalità guidato dall'uscita di un thread, sched_mm_cid_exit(), o dalla ricalcolo differito del max_cids in mm_cid_work_fn()).
In pratica, syzkaller ha segnalato la vulnerabilità come un use-after-free rilevato da KASAN in __schedule -> mm_cid_switch_to, dove l'offensiva clear_bit() è inlineata tramite mm_cid_schedout() -> mm_drop_cid().
Si protegge l'assegnazione del bit di transizione contro MM_CID_UNSET, oltre al controllo cid_in_transit() esistente, in modo che il bit venga impostato solo su un CID effettivamente appartenente a un task. Un CID posseduto dalla CPU (MM_CID_ONCPU) per un task attivo in esecuzione è gestito dal ramo cid_on_cpu(pcp->cid) sopra indicato e non raggiunge mai questo percorso; pertanto, escludere MM_CID_UNSET (e il caso già in transizione) è sufficiente.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.