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

net: stmmac: restore NET_IP_ALIGN 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
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.
Published: 2026-09-17
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: Kernel Panic (Denial of Service)
Action: Patch
AI Analysis

Impact

The bug in the STMMAC Ethernet driver removes the required NET_IP_ALIGN padding from the receive buffer offset. As a result, on architectures where the IP header must be aligned, the header lands at an unaligned memory address. This unaligned access triggers an alignment exception in the kernel, causing it to panic. The effect is a denial‑of‑service that crashes the entire host whenever a packet in the RX path misaligns the IP header.

Affected Systems

All Linux kernel builds that include the STMMAC driver in zero‑copy mode are potentially affected. The flaw exists in any kernel version prior to the commit that restores NET_IP_ALIGN to the RX offset. Affected vendors are the upstream Linux kernel maintainers; specific release versions are not listed in the advisory.

Risk and Exploitability

The EPSS score is listed as less than 1%, indicating a very low probability that the vulnerability is actively exploited in the wild. The CVSS score is 7.5, indicating a medium‑to‑high severity risk. The vulnerability is not currently in the CISA KEV catalog. Attackers would need network connectivity to the affected host and could trigger the kernel panic by sending normal packets, such as an ICMP echo request. Because the flaw causes a crash rather than privilege escalation or data disclosure, the risk is primarily a disruption of service. The lack of a high exploitation rate suggests that a cautious approach—verify whether the system is running a vulnerable kernel and apply the fix—suffices for mitigation.

Generated by OpenCVE AI on September 20, 2026 at 04:34 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply a Linux kernel update that includes the fix from commit df542f669307 which restores NET_IP_ALIGN to the RX offset.
  • If updating is not immediately possible, reconfigure the STMMAC driver to disable zero‑copy RX mode (e.g., set stmmac_zero_copy_rx=0 or build the driver without the zero‑copy option).
  • As a temporary measure, block or rate‑limit ICMP echo requests and other traffic that could trigger the misaligned RX path until the kernel can be updated.
  • After applying the patch or configuration change, reboot the affected systems to ensure the new driver state is in effect.

Generated by OpenCVE AI on September 20, 2026 at 04:34 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 20 Sep 2026 05:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-680

Fri, 18 Sep 2026 21:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}


Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net: stmmac: restore NET_IP_ALIGN 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 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.
Title net: stmmac: restore NET_IP_ALIGN in the RX DMA offset
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-18T17:52:49.224Z

Reserved: 2026-09-11T19:38:34.784Z

Link: CVE-2026-90059

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:16:54.590

Modified: 2026-09-18T18:17:40.213

Link: CVE-2026-90059

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T04:45:16Z

Weaknesses
  • CWE-680

    Integer Overflow to Buffer Overflow