CVE-2026-80789 in Linux
Riassunto
di VulDB • 04/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
nvmet-tcp: limitazione della lunghezza dei dati SGL prima dell'allocazione dei buffer di comando
nvmet_tcp_map_data() legge il valore a 32 bit sgl->length, controllato dall'host e, per il descrittore offset in-capsule (tipo 0x01), lo confronta con port->inline_data_size prima dell'utilizzo. Qualsiasi altro tipo di descrittore SGL -- incluso il descrittore del blocco dati SGL non inline per il trasporto (tipo NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, ovvero il tipo utilizzato da un host reale per le scritture out-of-capsule) -- salta completamente tale controllo e procede direttamente a:
cmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt);
con len preso direttamente dal canale di comunicazione (wire), non limitato fino a 4 GiB.
nvmet_req_init() analizza solo il comando e non ispeziona mai sgl->length; nvmet_check_transfer_len(), l'unico altro punto in cui transfer_len viene convalidato, viene eseguito successivamente, tramite req->execute(), dopo che l'allocazione è già avvenuta. Per un comando di scrittura, il target risponde con una R2T e mette in pausa (park) il comando attendendo che l'host invii i dati; se l'host (o un peer non autenticato che semplicemente non prosegue mai la comunicazione) non lo fa, il buffer allocato tramite sgl_alloc() rimane residente per tutta la durata del comando. NVMe/TCP non prevede una configurazione di autenticazione obbligatoria nella configurazione predefinita, quindi qualsiasi peer in grado di raggiungere il portal target e completare una connessione Fabrics può sfruttare questa vulnerabilità con un singolo comando manipolato ad hoc (crafted), ripetibile su più code e connessioni per amplificare l'attacco. Si tratta di un'allocazione non limitata della memoria del kernel attivata da un peer remoto, efficacemente non autenticato.
Convalidare len rispetto allo stesso limite NVMET_TCP_MAXH2CDATA già utilizzato dal file per limitare i dati H2C per PDU, per ogni tipo di descrittore SGL, prima di eseguire qualsiasi allocazione. Questo chiude la falla relativa ai descrittori non inline, mantenendo invariato il controllo più stringente su inline_data_size esistente per il caso in-capsule.
Verificato a runtime su una build KASAN v6.19: con tale limitazione applicata, un comando di scrittura manipolato ad hoc che trasporta una lunghezza SGL non-inline eccessiva viene rifiutato prima dell'esecuzione di sgl_alloc(), dove la stessa richiesta precedentemente causava un'allocazione del kernel non limitata di circa 256 MiB (fino a 4 GiB) che rimaneva residente in attesa di una R2T mai soddisfatta dall'host.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.