Public bug reported:
[linux-raspi] Kernel panic in bcmgenet_rx_poll / skb_release_data under
network load (kernel 7.0.0-1014-raspi, Ubuntu 26.04)
## Summary
Repeated, unrecoverable kernel panics on a Raspberry Pi 4 Model B
running Ubuntu 26.04, occurring under bursts of Ethernet receive
traffic. The panic happens inside the `bcmgenet` driver's RX NAPI poll
path while releasing an skb, and is fatal because it occurs in
interrupt/softirq context — the machine hard-resets with no shutdown
sequence and no trace left in the systemd journal (the crash is only
visible via the physical console or a photo of it).
## What I expected to happen
The system should remain up and stable under normal network load,
including brief bursts of traffic caused by restarting a Docker
container or acting as the LAN's DNS resolver — the same workload it
handled without issue prior to the 26.04 upgrade.
## What happened instead
The system hard-crashes (kernel panic) and silently reboots with no
shutdown sequence, typically within seconds to ~25 minutes of a burst of
inbound network traffic on `eth0`. This happened repeatedly (5+ times)
over one evening, always on kernel `7.0.0-1014-raspi`, and stopped
entirely after manually switching to kernel `6.17.0-1021-raspi`.
## System information
- **Ubuntu release:** output of `lsb_release -rd`:
```
Description: Ubuntu 26.04 LTS
Release: 26.04
```
- **Package version:** output of `apt-cache policy linux-image-raspi` /
`apt-cache policy linux-raspi`:
```
linux-image-raspi:
Installed: (none)
Candidate: 7.0.0-1014.14
Version table:
7.0.0-1014.14 500
500 http://archive.ubuntu.com/ubuntu resolute-updates/main arm64
Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main arm64
Packages
7.0.0-1009.9 500
500 http://archive.ubuntu.com/ubuntu resolute/main arm64 Packages
linux-raspi:
Installed: (none)
Candidate: 7.0.0-1014.14
Version table:
7.0.0-1014.14 500
500 http://archive.ubuntu.com/ubuntu resolute-updates/main arm64
Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main arm64
Packages
7.0.0-1009.9 500
500 http://archive.ubuntu.com/ubuntu resolute/main arm64 Packages
```
Note: `linux-image-raspi` / `linux-raspi` metapackages show "Installed:
(none)" because they were purged while working around this bug (see Workaround
section below) — the kernel that actually panicked was installed and running as
`linux-image-7.0.0-1014-raspi` prior to that.
- **Hardware:** Raspberry Pi 4 Model B, Rev 1.2
- **Install history:** freshly upgraded via `do-release-upgrade` from a prior
LTS release
- **Kernel (crashing):** `7.0.0-1014-raspi` (`#14-Ubuntu PREEMPT(lazy)`)
- **Kernel (confirmed stable, currently running as workaround):**
```
Linux pi-server 6.17.0-1021-raspi #21-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 19
17:27:57 UTC 2026 aarch64 GNU/Linux
ii linux-image-6.17.0-1021-raspi 6.17.0-1021.21 arm64 Linux kernel image
for version 6.17.0
```
- **Relevant hardware:** onboard Gigabit Ethernet (`bcmgenet`,
`fd580000.ethernet`), used as the primary NIC (`eth0`), static IP via
`systemd-networkd`
- **Workload at time of crash:** Docker containers running on `eth0`/host
networking, including Pi-hole (`pihole/pihole`) acting as the LAN's DNS
resolver, plus Portainer. Crashes correlated strongly with bursts of network
receive traffic — specifically: (a) restarting the Pi-hole container (`docker
compose down && up -d` / `docker compose restart`), and (b) pointing the LAN
router's DNS server at the Pi's IP, which caused a sudden increase in inbound
DNS query volume.
## Description
After a `do-release-upgrade` to 26.04, the system began hard-crashing
and silently rebooting at unpredictable intervals (anywhere from under a
minute to roughly an hour of uptime). Symptoms observed over several
hours of troubleshooting:
- No warning in `journalctl` — the log simply stops mid-stream with no shutdown
target reached, no `Stopping...`/`Shutting down` messages, and no kernel panic
entry (because the panic occurs after normal logging has effectively stopped
and before the reboot can flush anything further to persistent storage).
- `/sys/fs/pstore` was empty after every crash — no persisted panic record.
- ARP entries for the host remained valid during some failure windows (i.e. the
NIC was still answering ARP) while ICMP/SSH/DNS all timed out — consistent with
the crash occurring mid-packet-processing rather than a full power/hardware
fault.
- No evidence of: SD card I/O errors, filesystem corruption beyond journals cut
off mid-write (an expected symptom of the hard reset, not a cause), OOM kills,
thermal throttling, watchdog activity, firewall/ufw interference, or scheduled
timers.
- The failure was eventually caught live via HDMI console + photograph,
capturing a full kernel oops/panic (see below).
## Captured panic (transcribed from console photo)
```
[ 1251.343133] SET = 0, FnV = 0
[ 1251.347333] EA = 0, S1PTW = 0
[ 1251.351621] FSC = 0x04: level 0 translation fault
[ 1251.357687] Data abort info:
[ 1251.361719] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1251.368388] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1251.374470] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1251.380802] [0005f65ef4f0912e] address between user and kernel address ranges
[ 1251.389169] Internal error: Oops: 0000000096000004 [#1] SMP
[ 1251.396014] Modules linked in: veth nf_conntrack_netlink xt_nat xt_tcpudp
xt_conntrack
xt_MASQUERADE bridge stp llc xfrm_user xfrm_algo ip_set nf_tables x_tables
nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat overlay binfmt_misc
bcm_client_lib
input_leds drm_dma_helper drm_kms_helper vc_sm_cma v4l2_mem2mem
videobuf2_vmalloc
videobuf2_dma_contig videobuf2_common spidev raspberrypi_hwmon mmc_block
rpmb_core
i2c_bcm2835 bcm2835_mmc i2c_brcmstb spi_bcm2835 phy_generic nvmem_rmem autofs4
[...]
[ 1251.501546] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C E
[ 1251.513321] Tainted: [C]=CRAP, [E]=UNSIGNED_MODULE
[ 1251.518833] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[ 1251.525409] pstate: 60400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1251.533159] pc : skb_release_data+0x100/0x238
[ 1251.538237] lr : sk_skb_reason_drop+0x60/0x320
[ 1251.543427] sp : ffff800080003bf0
[ ... register dump omitted, available on request / in attached photo ... ]
[ 1251.629277] Call trace:
[ 1251.634300] skb_release_data+0x100/0x238 (P)
[ 1251.639300] sk_skb_reason_drop+0x60/0x320
[ 1251.644227] dev_kfree_skb_any_reason+0x64/0x80
[ 1251.640877] bcmgenet_rx_poll+0x48/0x1a0
[ 1251.653427] __napi_poll+0x44/0x2c0
[ 1251.657537] net_rx_action+0x124/0x500
[ 1251.661882] handle_softirqs+0x1c/0x420
[ 1251.666640] __do_softirq+0x1c/0x28
[ 1251.670473] do_softirq+0x18/0x30
[ 1251.674718] call_on_irq_stack+0x30/0x60
[ 1251.679427] do_softirq_own_stack+0x24/0x30
[ 1251.683990] irq_exit_rcu+0x18/0x30
[ 1251.688072] el1_interrupt+0x4c/0xb0
[ 1251.692423] el1h_64_irq_handler+0x18/0x30
[ 1251.696520] el1h_64_irq+0x84/0x88
[ 1251.701144] default_idle_call+0x38/0x170 (P)
[ 1251.705893] cpuidle_idle_call+0x4bc/0x240
[ 1251.709886] do_idle+0xb0/0x120
[ 1251.714388] cpu_startup_entry+0x3c/0x50
[ 1251.720084] rest_init+0x14/0x120
[ 1251.722611] start_kernel+0x8c/0x8
[ 1251.726204] primary_switched+0x88/0x90
[ 1251.734913] Code: 6b131813 8109ad3a b7000da3 370004f3 (f9400661)
[ 1251.741565] ---[ end trace 0000000000000000 ]---
[ 1251.746573] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 1251.753909] SMP: stopping secondary CPUs
[ 1251.758012] Kernel Offset: 0x4ce080000000 from 0xffff800000000000
[ 1251.764689] PHYS_OFFSET: 0x0
[ 1251.770400] CPU features: 0x00000000,40270004,00028000,0400021b
[ 1251.774000] Memory Limit: none
[ 1251.774458] ---[ end Kernel panic - not syncing: Oops: Fatal exception in
interrupt ]---
```
(Some digits/offsets above are transcribed from a photograph of the
console and may contain minor OCR-style errors — happy to provide the
original photos or re-capture with `netconsole`/serial console logging
if useful for triage.)
## Analysis
- Fault: NULL/invalid pointer dereference (`level 0 translation fault`,
"address between user and kernel address ranges") in `skb_release_data`, called
from `sk_skb_reason_drop` → `dev_kfree_skb_any_reason` → **`bcmgenet_rx_poll`**
→ `__napi_poll` → `net_rx_action`, i.e. during normal Ethernet receive
processing in softirq context.
- Because this happens inside a hardware interrupt/softirq handler, the kernel
cannot recover and panics immediately, causing an instant, silent hard reset
(BCM2835 watchdog is not what's rebooting the box — the panic path itself halts
and the SoC resets).
- This looks like the same general class of historical
`bcmgenet`/`skb_release_data` race condition reported previously for Raspberry
Pi 4 hardware (e.g. a 2021 netdev thread "Kernel Panic in skb_release_data
using genet" on mainline, and prior linux-raspi fixes such as "net: bcmgenet:
synchronize use of bcmgenet_set_rx_mode()"). It may be a regression of a
previously-fixed issue, or a new manifestation in the current
`7.0.0-1014-raspi` build.
- Strongly correlated with bursts of RX traffic: every reproducible crash
coincided with either (a) restarting a `network_mode: host` Docker container
bound to the same interface, or (b) a sudden increase in inbound DNS query
volume after pointing the LAN's DNS server at this host.
## Reproduction
Not reliably deterministic, but reproduced multiple times (5+ occurrences over
one evening) by:
1. Booting `7.0.0-1014-raspi` with `eth0` as the primary interface, Docker
running with at least one `network_mode: host` container bound to it.
2. Generating a burst of inbound network traffic on `eth0` — either by
restarting the host-networked container (`docker compose restart` / `down` +
`up -d`), or by directing an external DNS resolver's traffic at the host.
3. Panic typically occurred within seconds to ~25 minutes of the traffic burst.
## Workaround
Manually reverted the active kernel from `7.0.0-1014-raspi` to the
previously-installed `6.17.0-1021-raspi` by copying its
`vmlinuz`/`initrd.img`/dtb into `/boot/firmware/current/` (since `flash-
kernel` refuses to "downgrade" automatically) and holding `linux-image-
raspi` / `linux-image-7.0.0-1014-raspi` via `apt-mark hold`. System has
been stable on `6.17.0-1021-raspi` under the same workload (Pi-hole
restarts, router DNS pointed at the host) since the change.
## Attachments
- Two photographs of the console at the moment of panic (available on
request — not included inline here).
## Additional notes
- `dmesg`/`journalctl` are of no help in diagnosing this after the fact, since
the panic occurs late enough in shutdown that nothing further is flushed to the
persistent journal, and `/sys/fs/pstore` was never populated across ~6
occurrences. If there's a recommended way to capture this more reliably
(netconsole, kdump, panic-on-oops + reboot delay, serial console logging),
happy to set that up to gather a cleaner trace.
- Happy to test a `-proposed` kernel or apply a suggested patch on this
hardware if that would help confirm a fix.
ProblemType: Package
DistroRelease: Ubuntu 26.04
Package: linux-image-7.0.0-1014-raspi 7.0.0-1014.14
ProcVersionSignature: Ubuntu 6.17.0-1021.21-raspi 6.17.13
Uname: Linux 6.17.0-1021-raspi aarch64
ApportVersion: 2.34.0-0ubuntu2
Architecture: arm64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path',
'/dev/snd/controlC2', '/dev/snd/pcmC2D0p', '/dev/snd/controlC1',
'/dev/snd/pcmC1D0p', '/dev/snd/controlC0', '/dev/snd/pcmC0D0p', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CasperMD5CheckResult: unknown
CloudArchitecture: aarch64
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSubPlatform: config-disk (/dev/mmcblk0p1)
Date: Wed Jul 8 21:42:16 2026
ErrorMessage: old linux-image-7.0.0-1014-raspi package prerm maintainer script
subprocess failed with exit status 1
ImageMediaBuild: 20241007.1
IwDevWlan0Link: Not connected.
Lspci-vt: -[0000:00]---00.0-[01]----00.0 VIA Technologies, Inc. VL805/806 xHCI
USB 3.0 Controller
Lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 003: ID 17ef:6099 Lenovo Lenovo Traditional USB Keyboard
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 001: Dev 003, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=dwc2/1p, 480M
ProcFB: 0 vc4drmfb
ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1
snd_bcm2835.enable_headphones=0 numa_policy=interleave
nvme.max_host_mem_size_mb=0 snd_bcm2835.enable_headphones=1
snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0 numa=fake=2
system_heap.max_order=0 iommu_dma_numa_policy=interleave
smsc95xx.macaddr=DC:A6:32:AB:19:42 vc_mem.mem_base=0x3ec00000
vc_mem.mem_size=0x40000000 console=ttyS0,115200 multipath=off
dwc_otg.lpm_enable=0 console=tty1 root=LABEL=writable rootfstype=ext4 rootwait
fixrtc
Python3Details: /usr/bin/python3.14, Python 3.14.4, python3-minimal,
3.14.3-0ubuntu2
PythonDetails: N/A
RelatedPackageVersions:
dpkg 1.23.7ubuntu1
apt 3.2.0
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux-raspi
StagingDrivers: vc_sm_cma bcm2835_codec bcm2835_isp snd_bcm2835
bcm2835_mmal_vchiq bcm2835_v4l2
Title: package linux-image-7.0.0-1014-raspi 7.0.0-1014.14 failed to
install/upgrade: old linux-image-7.0.0-1014-raspi package prerm maintainer
script subprocess failed with exit status 1
UpgradeStatus: Upgraded to resolute on 2026-07-06 (2 days ago)
acpidump:
** Affects: linux-raspi (Ubuntu)
Importance: Undecided
Status: New
** Tags: apport-package arm64 arm64-image raspi-image resolute staging
** Attachment added: "IMG_4863.jpeg"
https://bugs.launchpad.net/bugs/2160182/+attachment/5980772/+files/IMG_4863.jpeg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160182
Title:
Kernel panic in bcmgenet_rx_poll/skb_release_data under network load
(7.0.0-1014-raspi, Ubuntu 26.04, Pi 4)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2160182/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
