Odebrany

CVE-2026-99081

opublikowano: 23.10.2026, 15:17

modyfikacja: 23.10.2026, 15:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

bnxt_en: napraw długość mapowania DMA dla małych pakietów z dopełnieniem

Stefan Fleischmann zgłosił błędy odczytu Intel IOMMU DMA na BCM57412
Karty sieciowe NetXtreme-E podczas przesyłania pakietów na interfejsach VLAN/macvlan:

DMAR: [Odczyt DMA NO_PASID] Żądaj urządzenia [18:00.0] adres błędu 0xfc499000
[przyczyna błędu 0x06] PTE Dostęp do odczytu nie jest ustawiony
bnxt_en 0000:18:00.0 eno1np0: Porzucenie wiadomości {0xb4 0x41a} len: 0 ze względu na stan oprogramowania: 0x2000001
...
NETDEV WATCHDOG: eno1np0 (bnxt_en): przekroczono limit czasu kolejki transmisji 0

Adres błędu (0xfc499000) znajduje się dokładnie na granicy strony 4 KB,
wskazując na przepełnienie bufora odczytu DMA.

W bnxt_start_xmit() pakiety mniejsze niż BNXT_MIN_PKT_SIZE (52 bajty),
takie jak 42-bajtowe nieoznaczone ramki ARP, są dopełniane:

if (długość < BNXT_MIN_PKT_SIZE) {
podkładka = BNXT_MIN_PKT_SIZE - długość;
if (skb_pad(skb, pad))
przejdź do tx_kick_pending;
długość = BNXT_MIN_PKT_SIZE;
}

mapowanie = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE);
...
dma_unmap_len_set(tx_buf, len, len);

Jednak „len” został wcześniej zainicjowany do skb_headlen(skb) (np. 42 bajty)
i pozostaje nieregulowany po wypełnieniu. W związku z tym dma_map_single() i
dma_unmap_len_set() mapuje i śledzi tylko 42 bajty.

Później programuje się sprzętowy deskryptor bufora TX z dopełnioną długością:

txbd->tx_bd_len_flags_type =
cpu_to_le32(((długość + podkładka) << TX_BD_LEN_SHIFT) | flagi |
TX_BD_FLAGS_PACKET_END);

Silnik karty NIC DMA otrzymuje zatem polecenie odczytania 52 bajtów z regionu, w którym
tylko 42 bajty zostały zmapowane przez DMA. Jeśli skb->data kończy się w pobliżu granicy 4 KB
(w obrębie bajtów „pad” następnej strony), sprzętowe przekroczenie odczytu DMA
na niezamapowaną sąsiednią stronę, powodując błąd IOMMU.

Ten problem został ujawniony po zatwierdzeniu 447cbe95ebb9 („vlan: fix skb_under_panic
i przyspiesza przy przełączaniu odciążania HW VLAN”), ponieważ rezerwacja dodatkowej sieci VLAN
zapas zaokrąglony LL_RESERVED_SPACE od 48 do 64 bajtów, przesuwanie skb->data
przesunięcia i potencjalnie powodować, że małe ramki będą lądować bezpośrednio na stronie
granice.

Napraw to, używając skb_put_padto(skb, BNXT_MIN_PKT_SIZE) w
bnxt_start_xmit(), przed próbkowaniem skb_shinfo(skb)->nr_frags,
ponieważ dopełnienie może zlinearyzować skb.
Dzięki temu skb->len i skb_headlen(skb) odzwierciedlają dopełniony rozmiar, więc
że dma_map_single() odwzorowuje pełny bufor i długość deskryptora wynosi
spójne. Usuwa to również tymczasową zmienną „pad” i logikę maskowania.

W przeciwnym razie dopełnienie odbywa się po gałęzi SW USO
bnxt_sw_udp_gso_xmit() uwzględni dopełnienie jako ładunek UDP
i wyślij go w dodatkowych segmentach.

Należy zauważyć, że segmenty SW USO nadal nie są dopełniane: w przypadku protokołu IPv4 jest to segment
przenoszący mniej niż 10 bajtów ładunku UDP (mały gso_size lub krótki
ostatni segment) jest wysyłany jako ramka krótsza niż BNXT_MIN_PKT_SIZE.
Jest to osobny problem, pozostawiony do wydania kolejnej łatki.

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.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve