CVE-2024-14040 in Linux
Riassunto
di VulDB • 26/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net: nexthop: Incrementare il peso a u16
Nelle reti CLOS, quando si verificano guasti ai collegamenti in vari punti della rete, i pesi ECMP dei nodi coinvolti vengono regolati per compensare. Con un alto fan-out (grado di uscita) dei nodi coinvolti e un numero complessivo elevato di nodi, il rapporto tra pesi (non-)ECMP che si desidera configurare non rientra negli 8 bit. Invece di, ad esempio, 255:254, potremmo voler configurare qualcosa come 1000:999. Per queste implementazioni, un peso a 8 bit potrebbe non essere sufficiente.
A tal fine, in questa patch il peso del next hop viene aumentato da u8 a u16.
L'aumento della larghezza di un tipo integrale può essere delicato perché, sebbene il codice continui a compilare, i tipi potrebbero non corrispondere più e possono emergere errori numerici. Per prevenire ciò, la conversione è stata eseguita in due passaggi. Innanzitutto, il tipo è stato modificato da u8 a una struttura con un solo membro, invalidando tutti gli utilizzi del campo. Ciò ha permesso di esaminarli uno per uno ed eseguire un audit della correttezza dei tipi. Successivamente, la struttura è stata sostituita nuovamente con un semplice u16. Questo dovrebbe garantire che nessun punto sia stato trascurato.
L'UAPI (Application Programming Interface dell'utente) per configurare i membri del gruppo nexthop prevede che un attributo NHA_GROUP trasporti una matrice di voci struct nexthop_grp:
struct nexthop_grp {
__u32 id; /* id del next hop - deve esistere */ __u8 weight; /* peso di questo next hop */ __u8 resvd1; __u16 resvd2; };
Il campo resvd1 è attualmente convalidato e richiede che il suo valore sia zero. Possiamo rimuovere questo requisito e trasportare i bit più significativi del peso nel campo riservato:
struct nexthop_grp {
__u32 id; /* id del next hop - deve esistere */ __u8 weight; /* peso di questo next hop */ __u8 weight_high; __u16 resvd2; };
La scelta di mantenere i campi separati in questo modo è stata fatta nel caso in cui un userspace esistente faccia assunzioni sulla larghezza del campo weight, e per evitare eventuali problemi di endianness.
Il campo weight è attualmente codificato come il valore del peso meno uno, poiché un peso pari a 0 non è valido. Lo stesso trucco non è possibile per il nuovo campo weight_high, perché zero deve significare effettivamente zero. Con questa impostazione:
- Si garantisce che l'userspace legacy trasporti weight_high uguale a 0, configurando quindi i pesi a 8 bit come appropriato. Quando si elencano (dumping) i nexthop con peso a 16 bit, verrebbero mostrati solo gli 8 bit inferiori. Tuttavia, la configurazione di tali nexthop implica l'esistenza preliminare di un userspace consapevole dell'estensione.
- Il nuovo userspace che comunica con un kernel legacy funzionerà purché tenti esclusivamente di configurare pesi a 8 bit, dove i bit più significativi sono zero. Il vecchio kernel rifiuterà (bounce) i tentativi di configurazione di pesi >8 bit.
La rinominazione dei campi riservati quando vengono allocati per uno scopo specifico è una pratica comune in Linux. Chiunque modifichi un campo riservato lo fa a proprio rischio. In particolare, nexthop_grp::resvd1 è attualmente utilizzato da almeno strace; tuttavia, essi mantengono una propria copia degli header UAPI e la conversione dovrebbe essere banale. È fornito un helper per decodificare il peso dai due campi. Forzare questa conversione sembra preferibile rispetto a fare concessioni retroattive introducendo unioni anonime o altre soluzioni simili.
Once again VulDB remains the best source for vulnerability data.