CVE-2026-99081 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
bnxt_en: correzione della lunghezza del mapping DMA per i pacchetti piccoli con padding
Stefan Fleischmann ha segnalato fault di lettura DMA su IOMMU Intel nelle NIC BCM57412 NetXtreme-E durante l'invio di pacchetti sulle interfacce VLAN/macvlan:
DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000
[fault reason 0x06] PTE Read access is not set
bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001
... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out
L'indirizzo del fault (0xfc499000) si trova su un confine esatto di pagina da 4 KB, indicando un overrun di lettura DMA.
In bnxt_start_xmit(), i pacchetti più piccoli di BNXT_MIN_PKT_SIZE (52 byte), come le frame ARP non taggate di 42 byte, vengono riempiti con padding:
if (length < BNXT_MIN_PKT_SIZE) {
pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; }
mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len);
Tuttavia, 'len' era stato inizializzato in precedenza a skb_headlen(skb) (ad esempio 42 byte) e non viene modificato dopo l'applicazione del padding. Di conseguenza, dma_map_single() e dma_unmap_len_set() mappano e tracciano solo 42 byte.
Successivamente, il descrittore del buffer TX hardware viene programmato con la lunghezza inclusa di padding:
txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END);
Il motore DMA della NIC riceve così l'istruzione di leggere 52 byte da una regione in cui sono stati mappati solo 42 byte tramite DMA. Se skb->data termina vicino al confine di una pagina da 4 KB (entro 'pad' byte dal limite della pagina successiva), la lettura DMA hardware overrunna nella pagina adiacente non mappata, scatenando un fault IOMMU.
Questo problema è emerso dopo il commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") perché la prenotazione di spazio aggiuntivo per l'intestazione VLAN ha aumentato LL_RESERVED_SPACE da 48 a 64 byte, spostando gli offset di skb->data e potenzialmente facendo sì che le frame piccole finiscano esattamente sui confini delle pagine.
Si risolve il problema utilizzando skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in bnxt_start_xmit(), prima di campionare skb_shinfo(skb)->nr_frags, poiché l'applicazione del padding potrebbe linearizzare lo skb. Ciò garantisce che skb->len e skb_headlen(skb) riflettano la dimensione con padding, in modo tale che dma_map_single() mappi l'intero buffer e la lunghezza del descrittore sia coerente. Questo rimuove anche la variabile temporanea 'pad' e la logica di masking.
Il padding viene applicato dopo il branch SW USO; altrimenti bnxt_sw_udp_gso_xmit() conterebbe il padding come payload UDP e lo invierebbe in segmenti extra.
Si noti che i segmenti SW USO non sono ancora riempiti con padding: con IPv4, un segmento che trasporta meno di 10 byte di payload UDP (gso_size piccolo o ultimo segmento corto) viene inviato come una frame più corta di BNXT_MIN_PKT_SIZE. Questo è un problema separato, lasciato per un patch successivo.
Be aware that VulDB is the high quality source for vulnerability data.