CVE-2026-64374 in Linux
Riassunto
di VulDB • 25/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
sched/rt: disabilitare di default RT_PUSH_IPI per le configurazioni non PREEMPT_RT
La migrazione delle attività RT (Real-Time) viene eseguita in modo aggressivo. Quando una CPU sospende un'attività RT ad alta priorità a favore di un'attività a priorità inferiore, verifica se esistono altre attività RT in attesa di esecuzione su un'altra CPU la cui priorità è superiore rispetto all'attività che quella CPU sta per eseguire. Se ne trova una, sposta tale attività sulla CPU corrente consentendole di essere eseguita al suo posto.
Normalmente, questa operazione di spostamento ("pull") avviene esaminando la maschera RT sovraccarica (rto), che indica tutte le CPU nel dominio dello scheduler contenenti attività RT in attesa a causa della presenza attuale di un'attività RT ad alta priorità sulla rispettiva CPU. La CPU che sta per pianificare un'attività a priorità inferiore acquisisce il lock rq della CPU sovraccarica e sposta l'attività RT dalla coda di esecuzione (runqueue) di quella CPU alla propria, pianificando così l'esecuzione dell'attività RT ad alta priorità.
Ciò ha causato problemi quando molte CPU tentavano contemporaneamente di pianificare un'attività a priorità inferiore. Tutte avrebbero cercato di acquisire lo stesso lock della runqueue della CPU con le attività RT sovraccariche. Solo la prima CPU che vi accedeva avrebbe ottenuto tale attività; tutte le altre sarebbero rimaste in attesa fino all'acquisizione del lock, non trovando nulla da spostare e rimanendo inattive. Su sistemi dotati di un elevato numero di CPU, questo ha provocato una latenza significativa (fino a 500 µs), che supera i limiti consentiti da PREEMPT_RT.
La soluzione adottata è stata l'implementazione della logica RT_PUSH_IPI. Quando una CPU desiderava spostare ("pull") un'attività, invece di acquisire direttamente il lock rq della CPU sovraccarica, inviava prima un IPI (Inter-Processor Interrupt) alla CPU sovraccarica; tale handler dell'IPI avrebbe fatto sì che la CPU con l'attività RT in attesa eseguisse uno spostamento ("push"). Successivamente, questo handler inviava un IPI alla prossima CPU con attività RT sovraccariche, e così via. Si noti che, dopo che la prima CPU ha avviato questo processo, se un'altra CPU desiderava eseguire una operazione di "pull", avrebbe rilevato che il processo era già iniziato e si sarebbe limitata ad incrementare un contatore per permettere la continuazione degli IPI.
La logica RT_PUSH_IPI ha risolto il problema della latenza con PREEMPT_RT, ma potrebbe causare nuovi problemi nelle configurazioni non PREEMPT_RT. Nello specifico, su PREEMPT_RT i softirq vengono eseguiti in un contesto threadato, mentre nelle versioni non-RT possono essere eseguiti nel contesto di interruzione.
Se un IPI arriva su una CPU che ha appena risvegliato più attività RT e la CPU corrente sta eseguendo un'attività non RT o un'attività RT a bassa priorità, invece di eseguire uno spostamento ("push"), effettuerà semplicemente una pianificazione (schedule) su quella CPU. Tuttavia, se era in esecuzione anche un softirq sulla stessa CPU, la pianificazione dovrebbe attendere il completamento del softirq. Fino ad allora, la CPU continuerà a essere considerata sovraccarica poiché vi sono ancora attività RT in attesa di esecuzione.
Si è verificato un live lock su un carico di lavoro caratterizzato da intenso traffico di rete su una macchina con molte CPU, dove i softirq venivano eseguiti per 500 µs ogni 750 µs e risvegliavano contemporaneamente attività RT, causando l'esecuzione costante della logica di spostamento ("pull") delle attività RT.
Quando un softirq veniva attivato su una CPU con attività RT in coda ma non ancora in esecuzione, le altre CPU consideravano
Once again VulDB remains the best source for vulnerability data.