Kernel Panic in `bcmgenet` Driver — Regression in `linux-rpi 6.18.20-1`

[amphiprion-symb]

Describe the bug

Summary

After upgrading linux-rpi from 6.18.18-3 to 6.18.20-1, the system experiences a network failure — and intermittently a full kernel panic — a few minutes after boot. The issue does not occur on 6.18.18-3. Downgrading immediately restores stability.

---

Observed Symptoms

1. Network failure (always)

Within a few minutes of boot, DNS resolution breaks entirely. systemd-resolved enters a degradation loop, cycling through DNS feature sets:

UDP+EDNS0 → UDP → TCP → UDP

All DNS lookups fail after this point, taking down any service dependent on name resolution (observed: spotifyd, syncthing).

2. Kernel panic (intermittent)

The network failure is sometimes preceded or accompanied by a kernel panic triggered in the bcmgenet RX polling path during a software interrupt.

---

Related Issues

The issue described here is probably (closely) related to the one discussed in this forum thread:
https://archlinuxarm.org/forum/viewtopic.php?f=67&t=14806&sid=f8ac94f5d6d7a362834080c2e075a6b0

---

Analysis

The panic originates in bcmgenet_rx_poll+0x318/0x660, which calls into dev_kfree_skb_any_reason → skb_release_data → kfree_skb_list_reason, where it crashes with a level-0 translation fault (null/unmapped pointer dereference) at virtual address 0x00000000418cfe84.

This is consistent with a use-after-free or double-free bug in the socket buffer (skb) management within the bcmgenet RX path: the driver is attempting to free an skb whose memory is no longer mapped, suggesting a pointer was either already freed or was never properly initialised.

The pre-panic journalctl output shows systemd-resolved cycling through degraded DNS feature sets (UDP+EDNS0 → UDP → TCP), indicating the NIC driver was already in a degraded state before the panic occurred.

Steps to reproduce the behaviour

Reproduction

1. Install linux-rpi 6.18.20-1 on a Raspberry Pi 4B running Arch Linux ARM.
2. Boot the system and establish normal network activity (e.g. run syncthing, spotifyd, or any service generating network RX traffic).
3. Within approximately 1–5 minutes, DNS resolution fails. A kernel panic may follow.

Confirmed stable: linux-rpi 6.18.18-3 — no crashes observed.

Device (s)

Raspberry Pi 4 Mod. B

System

System Information

Field	Value
Hardware	Raspberry Pi 4 Model B Rev 1.1
OS	Arch Linux ARM
Kernel (broken)	linux-rpi 6.18.20-1
Kernel (stable)	linux-rpi 6.18.18-3
Architecture	AArch64
NIC Driver	bcmgenet (Broadcom GENET)

---

vcgencmd version

Feb 11 2026 18:28:41 
Copyright (c) 2012 Broadcom
version ce768004a1c9657e60b33b0cc413d8e07320cb0d (clean) (release) (start)

Logs

Kernel Panic Output

Captured from serial console / TV display at time of crash:

[  67.742532] Unable to handle kernel paging request at virtual address 00000000418cfe84
[  67.742587] Mem abort info:
[  67.742526]   ESR = 0x0000000096000004
[  67.742567]   EC = 0x25: DABT (current EL), IL = 32 bits
[  67.742597]   SET = 0, FnV = 0
[  67.742623]   EA = 0, S1PTW = 0
[  67.742643]   FSC = 0x04: level 0 translation fault
[  67.742669] Data abort info:
[  67.742686]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  67.742708]   CM = 0, GCS = 0, WnR = 0, TnD = 0, TagAccess = 0
[  67.742738]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  67.742765] user pgtable: 4k pages, 48-bit VAs, pgd=0000000005a17c000
[  67.742797] [00000000418cfe84] pgd=0000000000000000, p4d=0000000000000000
[  67.742841] Internal error: Oops: General Fault [#1] SMP
[  67.743432] CPU: 0 UID: 1000 PID: 1091 Comm: syncthing Tainted: G   6.18.20-1-rpi #1 PREEMPT
[  67.743450] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
[  67.743530] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  67.743606]  pc : kfree_skb_list_reason+0x68/0x2b8
[  67.743634]  lr : kfree_skb_list_reason+0x48/0x2b8
[  67.743641]  sp : ffff800080003b40
[  67.743659] x29: ffff800080003b40 x28: ffff00004151ca00 x27: 0000000000000000
[  67.743691] x26: 0000000000000000 x25: ffff00004151c000 x24: ffffcc6a4a70e170
[  67.743722] x23: ffff00004151c000 x22: 0000000000000002 x21: 00000000410cfdb0 x18: 0000000000000010
[  67.743820] x17: ffff3399e2109a000 x16: ffff800000000000 x15: 0000000000000000
[  67.743870] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[  67.743911] x11: 0000000000000000 x10: 0000000000000000  x9: 0000000000000000
[  67.743943]  x8: ffff800080003c68  x7: 0000000000000000  x6: 000000000000003f
[  67.743977]  x5: 0000000000000040  x4: fffffffffffffe0   x3: 0000000000000028
[  67.744001]  x2: 0000000000000001  x1: 0000000000000000  x0: ffff800080003be0
[  67.744021] Call trace:
[  67.744032]  kfree_skb_list_reason+0x68/0x2b8 (P)
[  67.744056]  skb_release_data+0x118/0x188
[  67.744068]  skb_release_data+0x5c/0xc8
[  67.744081]  dev_kfree_skb_any_reason+0x4c/0x58
[  67.744093]  bcmgenet_rx_poll+0x318/0x660
[  67.744110]  __napi_poll+0x44/0x2a8
[  67.744132]  net_rx_action+0x240/0x338
[  67.744146]  handle_softirq+0x11c/0x350
[  67.744162]  __do_softirq+0x1c/0x30
[  67.744176]  ___do_softirq+0x28/0x38
[  67.744193]  call_on_irq_stack+0x30/0x88
[  67.744210]  do_softirq_own_stack+0x24/0x50
[  67.744227]  __irq_exit_rcu+0x10/0x108
[  67.744241]  irq_exit_rcu+0x18/0x38
[  67.744254]  el0_interrupt+0x18/0xc0
[  67.744270]  __el0_irq_handler_common+0x18/0x28
[  67.744285]  el0t_64_irq_handler+0x10/0x20
[  67.744300]  el0t_64_irq+0x198/0x1a0
[  67.744317] Code: 9122dc318 d503201f d503201f d503201f (b9404600)
[  67.744350] ---[ end trace 0000000000000000 ]---
[  67.744359] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[  67.745313] SMP: stopping secondary CPUs
[  67.746257] Memory Offset: 0x1c6a55000000 from 0xffff800000000000
[  67.747203] PHYS_OFFSET: 0x0
[  67.748134] CPU features: 0x0680000,04027800,40004000,0400421b
[  67.749561] Memory Limit: none
[  67.749561] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

Note: The above was transcribed from a photograph of the display. Some hex values in the register dump and the module list (truncated on the right edge of the display) may contain minor transcription errors.

Additional context

Workaround

Downgrade to linux-rpi 6.18.18-3 and pin the package in /etc/pacman.conf:

IgnorePkg = linux-rpi linux-rpi-headers

[nbuchwitz]

Thanks for the detailed report.

The only larger bcmgenet commit between 6.18.18 and 6.18.20 is e987bc1 ("net: bcmgenet: fix broken EEE by converting to phylib-managed state"), which enables EEE (Energy Efficient Ethernet) for the first time on the GENET MAC. I have been running this patch on a CM4 with EEE active against an EEE-capable switch for several days without issues, so I'm not yet sure it is the cause here - but it is the prime suspect.

Could you please:

Show the output of sudo ethtool --show-eee eth0 on 6.18.20 (while the network is still working, before the crash)
Try adding dtparam=eee=off to /boot/firmware/config.txt and check if that resolves the issue
Also test with 6.18.19 to narrow down the regression window
If eee=off fixes it, the EEE commit is likely the culprit despite working fine on my setup - it could be a link-partner-specific issue.

Also relevant: Can you reproduce the issue with Raspberry Pi OS running the latest 6.18 kernel?

[amphiprion-symb]

Thanks for the precise feedback and identifying the possibly related commit.

Here's the output of sudo ethtool --show-eee end0 on 6.18.20 before disabling EEE in '/boot/config.txt':

name:           genet
filename:       (builtin)
softdep:        pre: mdio-bcm-unimac
license:        GPL
file:           drivers/net/ethernet/broadcom/genet/genet
alias:          platform:bcmgenet
description:    Broadcom GENET Ethernet controller driver
author:         Broadcom Corporation
parm:           skip_umac_reset:Skip UMAC reset step (bool)
parm:           eee:Enable EEE (default Y) (bool)

After setting dtparam=eee=off in '/boot/config.txt' the output changes to

EEE settings for end0:
        EEE status: not supported

as expected.

The system is now running for about half an hour with EEE switched off and did not crash so far. Previously the network crashed typically very quickly after boot. I will keep you updated.

[nbuchwitz]

Thanks. What's about the question about rpi os? Arch tends do some stuff differently...

Also to what switch / router is the pi connected?

[nbuchwitz]

Unfortunately you copied the wrong output (looks like modinfo). I need the sudo ethtool --show-eee end0

[amphiprion-symb]

Sorry, here's the correct output of sudo ethtool --show-eee end0:

EEE settings for end0:
        EEE status: enabled - active
        Tx LPI: 34 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full

The connected swtich is a TP-LINK TL-SG1005D.

Deactivating EEE in '/boot/config.txt' did not resolve the problem, the kernel panic reoccurred.

I have not yet tested with RPi OS but can do so on the weekend.

[nbuchwitz]

Thanks for the update and the correct ethtool output. Good to hear that the EEE commit is probably not the root cause.

There are ~550 commits between 6.18.18 and 6.18.20, mostly stable backports. Without a clear candidate from code review, narrowing this down will require some testing. I haven't been able to reproduce the issue on RPi OS Trixie with a CM4 so far.

Looking forward to your test results with RPi OS - that would help rule out Arch-specific kernel config differences as a factor.

[graysky2]

ArchARM uses the bcm2711_defconfig applied to some distro defaults. It might be easier to simply build the problematic kernel version on ArchARM without applying the defaults. This would result in theoretically an identical config to that of RPiOS.

@amphiprion-symb - just take the linux-rpi PKGBUILD and comment out line 78 and 79:

...
  else
    make bcm2711_defconfig
#    cat ../archarm.diffconfig >> .config # comment this line
#    make olddefconfig # comment this line
  fi  

[df8oe]

Kernel is running for some arch-users fine, too. But for me not - too :) So I think it is not arch specific but specific to local configuration and/or using different services.

[amphiprion-symb]

I have tested the following now:

• installed linux-rpi 6.18.21-2 from the Arch Linux ARM core package repository → kernel panic occurred
• compiled linux-rpi 6.18.21-2 from source (with makepkg) with Arch-specific configs commented out in PKGBUILD as proposed by @graysky2 → network crash and kernel panic both occurred
• set up RPi OS on a second SD card but need some help to install the correct kernel (package) there, could you please provide some instructions, @nbuchwitz? Is there a repository with pre-compiled binaries I can add somehow?

[nbuchwitz]

You can use rpi-update

[graysky2]

Oh wow, the recent reverts that the RPi Foundation fork shipped do not boot? @pelwell @popcornmix

[nbuchwitz]

Which reverts / git hash do your refer to?

nbw@rpicm4:~ $ sudo rpi-update rpi-6.18.y
[...]
nbw@rpicm4:~ $ sudo reboot
[...]
nbw@rpicm4:~ $ uname -a
Linux rpicm4 6.18.21-v8+ #1 SMP PREEMPT Fri Apr 10 13:40:27 UTC 2026 aarch64 GNU/Linux

[graysky2]

The reverts from April 9th: https://github.com/raspberrypi/linux/commits/rpi-6.18.y/

[nbuchwitz]

Can't reproduce this here, latest HEAD of rpi-6.18.y is booting fine. Is there a splat or error message you can share?

[graysky2]

Can't reproduce this here, latest HEAD of rpi-6.18.y is booting fine. Is there a splat or error message you can share?

Nor I, 6.18.21-2-rpi on RPi4B.