CVE-2026-99081
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 40 - wyżej niż 40% wszystkich znanych CVE
Streszczenie
W jądrze Linux w sterowniku bnxt_en występuje błąd mapowania DMA dla małych pakietów z dopełnieniem. Funkcja bnxt_start_xmit() dopełnia pakiety mniejsze niż 52 bajty, ale długość przekazywana do dma_map_single() pozostaje niezmieniona, przez co karta sieciowa odczytuje więcej bajtów niż zmapowano, powodując błąd IOMMU i timeout kolejki transmisji.
Ocena ryzyka
Może to prowadzić do błędów DMA, resetów interfejsu sieciowego i utraty łączności na kartach Broadcom NetXtreme-E, zwłaszcza na interfejsach VLAN/macvlan. W skrajnych przypadkach nieprawidłowy odczyt DMA może naruszać izolację pamięci zapewnianą przez IOMMU.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-99081 lub zastosuj odpowiedni patch sterownika bnxt_en. Do czasu aktualizacji rozważ unikanie konfiguracji VLAN/macvlan na dotkniętych kartach BCM57412.
Inne podatności w Linux kernel bnxt_en driver
Zobacz wszystkie- CVE-2026-43260Wysokie
W jądrze Linuxa naprawiono podatność związaną z logiką usuwania kontekstu RSS w sterowniku bnxt_en. Problem polegał na tym, że nieprawidłowe sprawdzenie stanu interfejsu sieciowego prowadziło do wycieku VNIC w oprogramowaniu układowym, co mogło skutkować utratą aktywnych kontekstów RSS.
- CVE-2026-97570Wysokie
W jądrze Linux w sterowniku bnxt_en występuje błąd przepełnienia bufora (out-of-bounds) w funkcji bnxt_alloc_agg_idx. Gdy oprogramowanie układowe karty sieciowej zgłasza mniejszą liczbę równoczesnych TPA (np. 32) niż maksymalna, identyfikator TPA może przekroczyć rozmiar tablicy rx_tpa, co prowadzi do nieprawidłowego dostępu do pamięci i awarii jądra podczas rozruchu.
- CVE-2026-97569Niskie ryzyko· EPSS 11%
W jądrze Linux w sterowniku bnxt_en występuje błąd, który może doprowadzić do zatrzymania kolejki transmisji. Gdy sterownik odracza ukończenia dla serii pakietów, a następnie duży pakiet USO nie mieści się w małym pierścieniu, pierścień może zostać wypełniony pakietami bez ukończeń, co blokuje kolejkę na stałe. Problem dotyczy małych pierścieni (do 457 deskryptorów) i został naprawiony poprzez wyczyszczenie bitu NO_CMPL w funkcji bnxt_txr_db_kick().
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix DMA mapping length for padded small packets Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: 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 The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: 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); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length: txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB page (within 'pad' bytes of the next page), the hardware DMA read overruns into the unmapped adjacent page, triggering an IOMMU fault. This issue was exposed after commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") because reserving extra VLAN headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb->data offsets and potentially causing small frames to land right against page boundaries. Fix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags is sampled, because padding might linearize the skb. This ensures skb->len and skb_headlen(skb) reflect the padded size so that dma_map_single() maps the full buffer and the descriptor length is consistent. This also removes the temporary 'pad' variable and masking logic. The padding is done after the SW USO branch, otherwise bnxt_sw_udp_gso_xmit() would account the padding as UDP payload and send it in extra segments. Note that SW USO segments are still not padded: with IPv4, a segment carrying less than 10 bytes of UDP payload (small gso_size, or a short last segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE. This is a separate issue, left for a followup patch.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

