Skip to content

Kernel panic (page fault) in bpf_peers_present_if() via ure driver (RTL8156 USB 2.5GbE) #285

@dllr96

Description

@dllr96

Description

Repeated kernel panics (14 in 24 hours) on OPNsense 26.1.6 caused by a page fault in bpf_peers_present_if() triggered during USB packet transmission via the ure driver (Realtek RTL8156 USB 2.5GbE adapter). The adapter is used as the physical WAN interface (PPPoE parent).

The system is part of an HA/CARP pair (backup node). The master node has the same USB adapter but has not crashed yet.

Environment

  • OPNsense version: 26.1.6 (amd64)
  • FreeBSD version: 14.3-RELEASE-p10 stable/26.1-n272047-4ad47b697b0a SMP
  • Hardware: Fujitsu ESPRIMO Q556/2, Intel Core i5-7500T, 16 GB RAM
  • USB controller: Intel 100 Series/C230 Series xHCI (pci0:0:20:0)
  • USB device: Realtek RTL8156 USB 2.5GbE (VID:0x0bda PID:0x8156, bcdDevice:0x3104)
  • Interface: ue0 on ure0 (USB Ethernet), link at 2500Base-T full-duplex
  • Role: PPPoE parent interface (WAN uplink)

Panic info (from /var/crash/info.last)

Dump header from device: /dev/ada0p3
  Architecture: amd64
  Dump Length: 82432
  Dumptime: 2026-04-11 06:50:11 +0200
  Hostname: firewall04.mountech-it
  Magic: FreeBSD Text Dump
  Version String: FreeBSD 14.3-RELEASE-p10 stable/26.1-n272047-4ad47b697b0a SMP
  Panic String: page fault
  Dump Status: good

Stack trace (identical across all 14 crashes)

Tracing pid 15 tid 100062 td 0xfffff80005a10000
kdb_enter() at kdb_enter+0x33
panic() at panic+0x43
trap_pfault() at trap_pfault+0x3da
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0xffffffff80d0321b, rsp = 0xfffffe00c41bdc60, rbp = 0xfffffe00c41bdc60 ---
bpf_peers_present_if() at bpf_peers_present_if+0xb      <-- page fault here
usbpf_xfertap() at usbpf_xfertap+0x3a
usbd_pipe_start() at usbd_pipe_start+0x13c
usb_command_wrapper() at usb_command_wrapper+0x96
usbd_pipe_enter() at usbd_pipe_enter+0xda
usb_command_wrapper() at usb_command_wrapper+0x96
usbd_transfer_submit() at usbd_transfer_submit+0x610
ure_bulk_write_callback() at ure_bulk_write_callback+0x42a
usbd_callback_wrapper() at usbd_callback_wrapper+0x8a6
usb_command_wrapper() at usb_command_wrapper+0x96
usb_callback_proc() at usb_callback_proc+0xb9
usb_process() at usb_process+0xfe
fork_exit() at fork_exit+0x81
fork_trampoline() at fork_trampoline+0xe

The crash occurs at offset +0xb into bpf_peers_present_if(), suggesting a NULL or invalid pointer dereference when accessing the interface's BPF descriptor.

Crash timeline (all page fault)

# Timestamp
0 2026-04-10 10:24
1 2026-04-10 10:54
2 2026-04-10 11:44
3 2026-04-10 11:49
4 2026-04-10 13:03
5 2026-04-10 17:04
6 2026-04-10 23:39
7 2026-04-11 01:26
8 2026-04-11 03:28
9 2026-04-11 04:08
10 2026-04-11 04:27
11 2026-04-11 05:48
12 2026-04-11 06:35
13 2026-04-11 06:50

14 crashes in ~20 hours. No pattern in timing; appears random during normal traffic.

Possibly related upstream fix

FreeBSD commit 56c93859038f on stable/14 (Feb 6, 2025) by Zhenlei Huang: "bpf: Fix potential race conditions" — fixes a race in bpf_setif() where a dead BPF interface could be referenced, causing a kernel panic. This may address the root cause.

Also related: FreeBSD Bug #286573 ("panic in usbpf_xfertap()") reported on 14.3-STABLE.

Question: Has commit 56c93859038f been cherry-picked into the OPNsense stable/26.1 kernel fork?

dmesg (relevant)

xhci0: <Intel Sunrise Point USB 3.0 controller> at device 20.0 on pci0
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
ugen0.2: <Realtek USB 10/100/1G/2.5G LAN> at usbus0
ure0 on uhub0
ure0: <Realtek USB 10/100/1G/2.5G LAN, class 0/0, rev 3.20/31.04, addr 1> on usbus0
ue0: <USB Ethernet> on ure0
ue0: Ethernet address: 00:e0:33:68:00:25

Workaround

Currently mitigated by CARP HA — the master node handles all traffic while the backup node keeps crashing and rebooting. However, this defeats the purpose of HA redundancy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    upstreamThird party issue

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions