Odebrany

CVE-2026-99127

opublikowano: 28.10.2026, 12:17

modyfikacja: 28.10.2026, 12: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ę:

page_pool: wyrównaj frag_offset w przypadku żądań o nieparzystej wielkości

page_pool_alloc_frag_netmem() zaokrągla żądany rozmiar fragmentu za pomocą

rozmiar = ALIGN(rozmiar, dma_get_cache_alignment());

dma_get_cache_alignment() zwraca 1, chyba że architektura tak definiuje
ARCH_DMA_MINALIGN, czego nie mają architektury spójne z DMA, takie jak x86.
Tam funkcja ALIGN() nie daje żadnego efektu, a pula->frag_offset postępuje w sposób surowy,
niezaokrąglony rozmiar.

Pojedynczy obiekt wywołujący pytający o nieparzysty rozmiar pozostawia frag_offset źle wyrównany
za każdy fragment wyryty później na tej stronie. Basen jest wspólny,
więc szkoda nie ogranicza się do dzwoniącego, który ją spowodował.

System_page_pool na procesor używany przez ogólny XDP osiąga to.
skb_pp_cow_data() przydziela swoje fragmenty z surową długością pakietu:

rozmiar = min_t(u32, dł., PAGE_SIZE);
truesize = rozmiar;
strona = page_pool_dev_alloc(pool, &page_off, &truesize);

pozostawienie frag_offset nieparzystego dla tego, co zostanie wyryte na następnej stronie. Jego
własny przydział głowicy jest już wyrównany - SKB_HEAD_ALIGN(rozmiar) plus
XDP_PACKET_HEADROOM jego wywołujący przechodzą - więc jest to późniejszy użytkownik udostępniony
pula, która płaci: page_pool_dev_alloc_va() zwraca źle wyrównany bufor,
napi_build_skb() instaluje go jako skb->head i skb_shinfo(skb) ==
skb->head + skb->end jest z nim źle wyrównany.

skb_shinfo()->dataref to 4-bajtowy obiekt atomic_t z przesunięciem 0x20, więc
atomic_inc() w __skb_clone() znajduje się na linii pamięci podręcznej. Na x86 z podziałem
wykrywanie blokady - domyślnie krytyczne dla blokad podziału jądra - powoduje panikę
maszyna:

Ups: wykryto blokadę podziału
RIP: 0010:skb_clone+0x154/0x1e0
Zadzwoń do śledzenia:
<przerwanie>
raw_local_deliver+0x1ed/0x2c0
ip_protocol_deliver_rcu+0x54/0x1c0
ip_local_deliver_finish+0x85/0x100
ip_local_deliver+0x67/0x100
__netif_receive_skb_one_core+0x85/0xa0
zaległości_procesu+0x87/0x130

Reprodukowane poprzez dołączenie dowolnego programu XDP działającego w trybie ogólnym do pętli zwrotnej i
otwarcie gniazda RAW IPPROTO_UDP, co powoduje klonowanie raw_local_deliver().
każdy lokalnie dostarczony pakiet UDP; następnie uruchamia go zwykły ruch DNS,
mniej więcej raz na 2500 klonów. Obserwowano 6.12.101 i 7.1.8.

Śledzenie page_pool_alloc_frag_netmem() w jednym takim uruchomieniu pokazuje
wzmocnienie — dwa żądania o nieparzystej wielkości, dziewięć źle ustawionych przesunięć:

żądany rozmiar & 7: 0: 17035 5: 1 7: 1
frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5

i skb_pp_cow_data() zwracające głowy, które zostały wyrównane przy wejściu:

głowa 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4)
głowa 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5)

Zaokrąglij rozmiar fragmentu przynajmniej do struktury wyrównania skb_shared_info
wymaga, więc fragmenty są zawsze odpowiednio dopasowane do obiektów wywołujących
na nich budować. Architektury wymagające większego wyrównania DMA zachowują to.

To również sprawia, że reszta jest obliczana w page_pool_alloc_netmem(),

*rozmiar = maksymalny_rozmiar - *przesunięcie;

wyrównane, ponieważ max_size jest potęgą dwójki - co naprawia dopasowanie
niewspółosiowość skb->end.

Zweryfikowano za pomocą kontrolowanego A/B w ramach QEMU/KVM: to samo drzewo, ta sama konfiguracja,
ten sam kompilator, te same rootfs i identyczny ruch, różniący się tylko tym
łatka. Program SEC("xdp.frags") XDP_PASS na datagramach lo i UDP
większy niż max_head_size steruje pętlą fragmentów skb_pp_cow_data(), która
przekazuje surowe długości pakietów do puli. Mierzone na powrocie
skb_pp_cow_data():

niezałatany, załatany
skb_pp_cow_data dzwoni pod numer 40800 40800
źle wyrównane skb->head 1120 0
dataref przy przesunięciu linii > 60 80 0

Ostatni wiersz zlicza dostępy, które faktycznie powodują błąd:
skb_shinfo()->dataref znajduje się na początku+końcu+0x20 i jest 4-bajtowym elementem atomowym, więc
`lock incl` dzieli 64-bajtową linię pamięci podręcznej tylko wtedy, gdy ten adres wyląduje na
przesunięcie 61..63. Wszystkie 80 wystąpień miało przesunięcie 61; – poinformowała panika
powyżej znajdowało się w przesunięciu 62. Wyeliminowanie niewspółosiowości powoduje usunięcie wszystkich
z nich.

Błąd tej samej klasy, co w przypadku zatwierdzenia 3bed3cc4156e („net: Nie przydzielaj page
fragmenty t
---obcięty---

In the Linux kernel, the following vulnerability has been resolved:

page_pool: keep frag_offset aligned for odd-sized requests

page_pool_alloc_frag_netmem() rounds the requested fragment size with

size = ALIGN(size, dma_get_cache_alignment());

dma_get_cache_alignment() returns 1 unless the architecture defines
ARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not.
There the ALIGN() is a no-op and pool->frag_offset advances by the raw,
unrounded size.

A single caller asking for an odd size then leaves frag_offset misaligned
for every fragment carved out of that page afterwards. The pool is shared,
so the damage is not confined to the caller that caused it.

The per-cpu system_page_pool used by generic XDP hits this.
skb_pp_cow_data() allocates its fragments with the raw packet length:

size = min_t(u32, len, PAGE_SIZE);
truesize = size;
page = page_pool_dev_alloc(pool, &page_off, &truesize);

leaving frag_offset odd for whatever is carved out of that page next. Its
own head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the
XDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared
pool that pays: page_pool_dev_alloc_va() returns a misaligned buffer,
napi_build_skb() installs it as skb->head, and skb_shinfo(skb) ==
skb->head + skb->end is misaligned with it.

skb_shinfo()->dataref is a 4-byte atomic_t at offset 0x20, so the
atomic_inc() in __skb_clone() straddles a cache line. On x86 with split
lock detection -- fatal for kernel split locks by default -- this panics
the machine:

Oops: Split lock detected
RIP: 0010:skb_clone+0x154/0x1e0
Call Trace:
<IRQ>
raw_local_deliver+0x1ed/0x2c0
ip_protocol_deliver_rcu+0x54/0x1c0
ip_local_deliver_finish+0x85/0x100
ip_local_deliver+0x67/0x100
__netif_receive_skb_one_core+0x85/0xa0
process_backlog+0x87/0x130

Reproduced by attaching any generic-mode XDP program to loopback and
opening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone
every locally delivered UDP packet; ordinary DNS traffic then triggers it,
roughly once per 2500 clones. Observed on 6.12.101 and 7.1.8.

Tracing page_pool_alloc_frag_netmem() over one such run shows the
amplification -- two odd-sized requests, nine misaligned offsets:

requested size & 7: 0: 17035 5: 1 7: 1
frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5

and skb_pp_cow_data() returning heads that were aligned on entry:

head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4)
head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5)

Round the fragment size up to at least the alignment struct skb_shared_info
requires, so fragments are always suitably aligned for the objects callers
build on them. Architectures needing a larger DMA alignment keep it.

This also makes the remainder computed in page_pool_alloc_netmem(),

*size = max_size - *offset;

aligned, since max_size is a power of two -- which fixes the matching
misalignment of skb->end.

Verified with a controlled A/B under QEMU/KVM: same tree, same config,
same compiler, same rootfs and identical traffic, differing only by this
patch. A SEC("xdp.frags") XDP_PASS program on lo plus UDP datagrams
larger than max_head_size drives skb_pp_cow_data()'s fragment loop, which
passes raw packet lengths to the pool. Measured at the return of
skb_pp_cow_data():

unpatched patched
skb_pp_cow_data calls 40800 40800
misaligned skb->head 1120 0
dataref at line offset >60 80 0

The last row counts the accesses that actually fault:
skb_shinfo()->dataref sits at head+end+0x20 and is a 4-byte atomic, so
`lock incl` splits a 64-byte cache line only when that address lands at
offset 61..63. All 80 occurrences were at offset 61; the panic reported
above was at offset 62. Eliminating the misalignment removes every one
of them.

Same class of bug as commit 3bed3cc4156e ("net: Do not allocate page
fragments t
---truncated---

>_ 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