Look up another CVE · open CVE-2026-90059 in the interactive tracker

CVE-2026-90059

net: stmmac: restore NET_IP_ALIGN in the RX DMA offset

7.5 EPSS 0.6% AV:N

Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-90059 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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 napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The conversion moved the headroom into stmmac_rx_offset() but did not carry over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP header now lands misaligned: 64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98 Same for the XDP branch: 256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290 On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 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 icmp_echo+0x38/0xa8 LR is at icmp_rcv+0x22c/0x370 Call trace: icmp_echo from icmp_rcv+0x22c/0x370 icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0 ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118 ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0 ... napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo(). Fix by adding NET_IP_ALIGN 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 stmmac_rx_offset(), so the extra bytes are accounted for.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

What this is: STMMAC ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/stmicro/stmmac/ · netdev@vger.kernel.org · Maintained
Kernel module: stmmac

Check it on the machine

grep -wE 'CONFIG_ETHERNET|CONFIG_NET_VENDOR_STMICRO|CONFIG_STMMAC_ETH' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w stmmac

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le
trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x

M: a module where it is built at all; some flavours do not build it

Build switches: CONFIG_ETHERNET, CONFIG_NET_VENDOR_STMICRO, CONFIG_STMMAC_ETH
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-17 (31 days ago)source
CVSS: 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.61%, higher than 48.1% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.14	6.18.52	2ea42936416b
6.14	7.2.6	c0d3f9560cc8
6.14	7.3	23680bf5f8c6

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: An IPv4 ICMP Echo Request received by the stmmac MAC is DMA'd at buf->page_offset from stmmac_rx_offset() (NET_SKB_PAD without NET_IP_ALIGN), turned into an skb by napi_build_skb() in stmmac_rx(), and delivered via napi_gro_receive() to ip_local_deliver() → icmp_rcv() → icmp_echo(); ICMP over Ethernet is a routable IP protocol.
AC:LAttack complexity, low: On ARM32, where NET_IP_ALIGN is 2, a single well-formed Echo Request is enough: stmmac_rx() always presents the packet 2 bytes off, so icmp_echo()'s `*icmp_hdr(skb)` ldm traps with no race, no special layout, and no attacker-uncontrolled state.
PR:NPrivileges required, none: icmp_echo() is invoked from icmp_rcv() via ip_protocol_deliver_rcu() on the unauthenticated IPv4 input path; no socket, credentials, or capability is checked before the misaligned header load.
UI:NUser interaction, none: The attacker sends the Echo Request themselves; stmmac_interrupt() → stmmac_napi_check() → stmmac_napi_poll_rx() → stmmac_rx() processes it with no victim action.
S:UScope, unchanged: The alignment exception and panic occur in the host kernel while icmp_echo() runs from NAPI/softirq on the received skb; no VM, IOMMU, or other security authority is crossed.
C:NConfidentiality impact, none: The faulting ldm in icmp_echo() copies the attacker's own 8-byte ICMP header into a stack-local icmp_bxm; it does not read unrelated kernel memory, and the trap yields a panic rather than a disclosure primitive.
I:NIntegrity impact, none: The trapping instruction is a load (`*icmp_hdr(skb)`), not a store; the missing NET_IP_ALIGN only misaligns the DMA start inside the page-pool buffer and does not create an out-of-bounds write or other modification primitive.
A:HAvailability impact, high: On ARM32 the unaligned ldm of *icmp_hdr(skb) in icmp_echo() raises "Unhandled fault: alignment exception" from NAPI context and panics the kernel ("Fatal exception in interrupt"), as shown on Altera SOCFPGA Arria10.