CVE-2026-99127

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