[Corrected 2026-09-11] This post originally attributed an MPU fault to the missing 7c4ea9a9d5. That was wrong — backporting it did not stop the fault, which looks like a separate Zephyr upstream defect that I will continue to look into. The request below, for the two missing commits (7c4ea9a9d5 and 67ed7813), is unaffected.
--- Original post ---
Setup: nRF54LM20-DK as host, W5500 Ethernet over SPI in MACRAW mode. Our tree is sdk-nrf af15896d9e, pinning zephyr 0e25e661.
Under sustained load (1 MB HTTP GET every 17 s, plus background broadcast/multicast traffic) our board takes an MPU fault in the eth_w5500 thread and halts:
<err> os: ***** MPU FAULT ***** Data Access Violation MMFAR Address: 0x2649
<err> os: Current thread: 0x20000388 (eth_w5500)
<err> os: Halting system
It survived 151 cycles / 47 minutes before faulting.
The cause is drivers/ethernet/eth_w5500.c missing upstream 7c4ea9a9d5 — "drivers: eth: w5500: reject header <= 2 before length subtraction", merged in Zephyr main on 2026-06-16.
That commit describes the mechanism we hit: "A value of 0, 1, or 2 underflows the uint16_t, causing an extremely large allocation followed by a NULL fragment dereference."
Backporting just that guard fixes it. The identical test now runs 182 minutes / 569 cycles with no fault, through 18 load spikes, where it previously crashed at 47 minutes.
While checking, a second fix is also absent from the zephyr revision sdk-nrf main currently pins (62923172, 2026-09-07): 67ed7813 / PR 109758 — "net: ip: icmpv6: drop errors for
mcast/unspecified sources", merged 2026-07-20. That one is already on ncs-v3.4-branch but not on main.
Which NCS release will these land in? We can carry local patches until then, we just need to know how long.
