CVE-2026-90059: net: stmmac: restore NET_IP_ALIGN in the RX DMA offset

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

net: stmmac: restore NETIPALIGN in the RX DMA offset

Since the RX path was converted to zero-copy, the page pool page is handed to the stack directly as the skb head, and the offset the DMA engine writes at is what determines the alignment of the packet headers.

Before the conversion the payload was copied into an skb obtained from napiallocskb(), which reserves NETSKBPAD + NETIPALIGN. The conversion moved the headroom into stmmacrxoffset() but did not carry over NETIPALIGN, so on architectures where NETIPALIGN is 2 the IP header now lands misaligned:

64 (NETSKBPAD) + 14 (ethernet) + 20 (IP) = 98

Same for the XDP branch:

256 (XDPPACKETHEADROOM) + 14 (ethernet) + 20 (IP) = 290

On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIGHAVEEFFICIENTUNALIGNEDACCESS is set.

Any received echo request panics the machine, e.g:

Unhandled fault: alignment exception (0x001) at 0x81873062 Internal error: : 1 [#1] SMP ARM Hardware name: Altera SOCFPGA Arria10 PC is at icmpecho+0x38/0xa8 LR is at icmprcv+0x22c/0x370 Call trace: icmpecho from icmprcv+0x22c/0x370 icmprcv from ipprotocoldeliverrcu+0x2c/0x224 ipprotocoldeliverrcu from iplocaldeliver+0xc8/0x1a0 iplocaldeliver from ipsublistrcvfinish+0x3c/0x50 ipsublistrcvfinish from iplistrcvfinish+0x110/0x118 iplistrcvfinish from iplistrcv+0xc8/0xdc iplistrcv from netifreceiveskblistcore+0x170/0x1c0 ... napicompletedone from stmmacnapipollrx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt

The faulting instruction is the ldm of icmphdr(skb) in icmpecho().

Fix by adding NETIPALIGN back to the RX offset, which restores the alignment the stack used to get.

Note that commit a955318fe67e ("stmmac: align RX buffers") made a similar change in 2021 and was reverted by commit 12d125b4574b ("stmmac: Revert "stmmac: align RX buffers"") because it caused packet corruption. That patch raised the offset from 0 without adjusting the buffer size accounting, so the DMA engine could arguably write past the end of the RX buffers, though this was never root caused. Commit df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") since derives the page pool allocation from stmmacrxoffset(), so the extra bytes are accounted for.