Regression #13176


UPnP port mappings cause kernel panic

Added by Steve Wheeler 3 months ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Force Exclusion
Affected Version:
Affected Architecture:


Adding a port mapping via UPnP causes a kerlnel panic in 22.05.

Tested here using GUPnP Universal control point. Status queries works as expected.
I tried to add a port mapping, here for port 55555. ~10s later there is a kernel panic:

db:0:kdb.enter.default>  bt
Tracing pid 74547 tid 100613 td 0xfffff8014c1b2740
kdb_enter() at kdb_enter+0x37/frame 0xfffffe003293ef70
vpanic() at vpanic+0x194/frame 0xfffffe003293efc0
panic() at panic+0x43/frame 0xfffffe003293f020
trap_fatal() at trap_fatal+0x38f/frame 0xfffffe003293f080
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe003293f0e0
calltrap() at calltrap+0x8/frame 0xfffffe003293f0e0
--- trap 0xc, rip = 0xffffffff810a8fef, rsp = 0xfffffe003293f1b0, rbp = 0xfffffe003293f1e0 ---
pf_krule_to_nvrule() at pf_krule_to_nvrule+0x55f/frame 0xfffffe003293f1e0
pfioctl() at pfioctl+0x79cf/frame 0xfffffe003293f6d0
devfs_ioctl() at devfs_ioctl+0xb0/frame 0xfffffe003293f720
VOP_IOCTL_APV() at VOP_IOCTL_APV+0x7b/frame 0xfffffe003293f750
vn_ioctl() at vn_ioctl+0x16c/frame 0xfffffe003293f860
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe003293f880
kern_ioctl() at kern_ioctl+0x298/frame 0xfffffe003293f8f0
sys_ioctl() at sys_ioctl+0x100/frame 0xfffffe003293f9c0
amd64_syscall() at amd64_syscall+0x387/frame 0xfffffe003293faf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe003293faf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004960da, rsp = 0x7fffffffdc78, rbp = 0x7fffffffdce0 -


22.05-BETA (amd64)
built on Mon May 16 06:21:03 UTC 2022

Also appears in arm7 as:

Enter an option: Fatal kernel mode data abort: 'Translation Fault (L2)' on read
trapframe: 0xde6e9610
FSR=00000007, FAR=00000000, spsr=20000013
r0 =00000003, r1 =00000001, r2 =00000000, r3 =00000000
r4 =00000000, r5 =00000003, r6 =00000000, r7 =00000001
r8 =df818320, r9 =dfa70800, r10=00000000, r11=de6e96d8
r12=fefefeff, ssp=de6e96a0, slr=c004b898, pc =c0771f88

panic: Fatal abort
cpuid = 1
time = 1652746601
Uptime: 12m30s

Actions #2

Updated by Marcos M 3 months ago

Tested with 22.05.b.20220513.0600 on a ESXi VM by running a network test on a Playstation 5; the result gave NAT2 (correct), then the panic happened.

db:0:kdb.enter.default>  show registers
cs                        0x20
ds                        0x3b  ll+0x1a
es                        0x3b  ll+0x1a
fs                        0x13
gs                        0x1b
ss                        0x28  ll+0x7
rax                       0x12
rcx                        0x1
rdx         0xfffffe006bb35f60
rbx         0xffffffff81665366
rsp         0xfffffe006bb36060
rbp         0xfffffe006bb36070
rsi                       0x30  ll+0xf
rdi         0xffffffff832a1588  vt_conswindow+0x10
r8                           0
r9                        0x20
r10         0xffffffff832a1578  vt_conswindow
r11                      0x133  ll+0x112
r12         0xffffffff81582a7d
r13         0xfffffe006bb361f0
r14                      0x100  ll+0xdf
r15         0xfffff80141baa000
rip         0xffffffff80dd25f7  kdb_enter+0x37
rflags                    0x86  ll+0x65
kdb_enter+0x37: movq    $0,0x28feb16(%rip)
db:0:kdb.enter.default>  run lockinfo
db:1:lockinfo> show locks
No such command; use "help" to list available commands
db:1:lockinfo>  show alllocks
No such command; use "help" to list available commands
db:1:lockinfo>  show lockedvnods
Locked vnodes
db:0:kdb.enter.default>  show pcpu
cpuid        = 0
dynamic pcpu = 0xd50140
curthread    = 0xfffff80141baa000: pid 30861 tid 100621 "pfctl" 
curpcb       = 0xfffff80141baa5a0
fpcurthread  = 0xfffff80141baa000: pid 30861 "pfctl" 
idlethread   = 0xfffff80005336000: tid 100003 "idle: cpu0" 
curpmap      = 0xfffff80225acb138
tssp         = 0xffffffff8371aea0
commontssp   = 0xffffffff8371aea0
rsp0         = 0xfffffe006bb36cc0
kcr3         = 0x800000022ad6c383
ucr3         = 0x800000022a78eb83
scr3         = 0x22a78eb83
gs32p        = 0xffffffff837216b8
ldt          = 0xffffffff837216f8
tss          = 0xffffffff837216e8
tlb gen      = 2078553
curvnet      = 0xfffff80005090a40
db:0:kdb.enter.default>  bt
Tracing pid 30861 tid 100621 td 0xfffff80141baa000
kdb_enter() at kdb_enter+0x37/frame 0xfffffe006bb36070
vpanic() at vpanic+0x194/frame 0xfffffe006bb360c0
panic() at panic+0x43/frame 0xfffffe006bb36120
trap_fatal() at trap_fatal+0x38f/frame 0xfffffe006bb36180
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe006bb361e0
calltrap() at calltrap+0x8/frame 0xfffffe006bb361e0
--- trap 0xc, rip = 0xffffffff810a8fef, rsp = 0xfffffe006bb362b0, rbp = 0xfffffe006bb362e0 ---
pf_krule_to_nvrule() at pf_krule_to_nvrule+0x55f/frame 0xfffffe006bb362e0
pfioctl() at pfioctl+0x79cf/frame 0xfffffe006bb367d0
devfs_ioctl() at devfs_ioctl+0xb0/frame 0xfffffe006bb36820
VOP_IOCTL_APV() at VOP_IOCTL_APV+0x7b/frame 0xfffffe006bb36850
vn_ioctl() at vn_ioctl+0x16c/frame 0xfffffe006bb36960
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe006bb36980
kern_ioctl() at kern_ioctl+0x298/frame 0xfffffe006bb369f0
sys_ioctl() at sys_ioctl+0x100/frame 0xfffffe006bb36ac0
amd64_syscall() at amd64_syscall+0x387/frame 0xfffffe006bb36bf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe006bb36bf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004960da, rsp = 0x7fffffffdc78, rbp = 0x7fffffffdce0 ---
Actions #3

Updated by Kristof Provost 3 months ago

The panic appears to be in the `nvlist_add_number(nvl, "timestamp", pf_get_timestamp(rule));` line in pf_krule_to_nvrule().
That's very likely because the timestamp doesn't get allocated in DIOCCHANGERULE. We should move that allocation from pf_ioctl_addrule() to pf_krule_alloc().

Actions #4

Updated by Kristof Provost 3 months ago

I'll merge that, and merge the change to plus-devel-12 as well.

Actions #5

Updated by Kristof Provost 3 months ago

  • Status changed from New to Feedback

This will be fixed in the next snapshot.

Actions #6

Updated by Marcos M 3 months ago

Tested on 22.05.b.20220517.1621, port mapping is now created and no panic is triggered.

Actions #7

Updated by Steve Wheeler 3 months ago

  • Status changed from Feedback to Resolved

This looks good here too:

[22.05-BETA][root@4100-2.stevew.lan]/root: pfctl -a miniupnpd -vsn
rdr pass quick on ix3 inet proto tcp from any to any port = 55555 keep state label "Test" rtable 0 -> port 55555
  [ Evaluations: 10        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 83821 State Creations: 0     ]


22.05-BETA (amd64)
built on Tue May 17 16:41:01 UTC 2022

Actions #8

Updated by Jim Pingle 3 months ago

  • Release Notes changed from Default to Force Exclusion

Not a problem in a release, so excluding from release notes.


Also available in: Atom PDF