Page MenuHomeFreeBSD

bpf: don't move an already-detached bpf_if in bpf_vmove
Needs ReviewPublic

Authored by seuros on Aug 8 2026, 7:47 PM.
Tags
None
Referenced Files
F175412543: D58734.id183697.diff
Sat, Oct 10, 4:38 PM
Unknown Object (File)
Sat, Oct 10, 12:55 AM
Unknown Object (File)
Fri, Oct 9, 1:03 PM
Unknown Object (File)
Thu, Oct 8, 11:12 PM
Unknown Object (File)
Mon, Oct 5, 10:53 PM
Unknown Object (File)
Mon, Oct 5, 8:59 AM
Unknown Object (File)
Sat, Oct 3, 8:52 PM
Unknown Object (File)
Thu, Oct 1, 7:05 PM
Subscribers

Details

Summary

if_vmove() unconditionally called bpf_vmove(), even after bpfdetach()
has replaced if_bpf with the dead_bpf_if sentinel. bpf_vmove() then
treated the sentinel as a live bpf_if and corrupted its list linkage,
panicking under QUEUE_MACRO_DEBUG on epair vnet teardown.

panic: bpf_vmove: Bad link elm ... next->prev != elm

Exported the sentinel via bpf_dead_if() so bpf_vmove() can recognize it
and skip it.

MFC: 1 week

Test Plan
  1. Create a VNET jail and give it one peer of an epair(4):

    jail -c name=t vnet persist ifconfig epair0 create ifconfig epair0a vnet t
  1. Inside the jail, bring the interface up and generate some traffic (anything that attaches bpf works dhclient, tcpdump -i epair0a, ect.)
  1. Destroy the jail:

    jail -r t

I was configuring forgejo, blackship and a test runner.. Happens in current and 15.1

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 75462
Build 72345: arc lint + arc unit

Event Timeline

seuros requested review of this revision.Aug 8 2026, 7:47 PM

How can I reproduce the problem?

I was writing the instructions in the test plan.

I have a blackship manifest that reproduce it 100%

Btw the system has WITNESS , INVARIANTS enabled.