Regression #13176
closedUPnP port mappings cause kernel panic
0%
Description
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 -
Tested:
22.05-BETA (amd64) built on Mon May 16 06:21:03 UTC 2022 FreeBSD 12.3-STABLE
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
Updated by Steve Wheeler over 2 years ago
Updated by Marcos M over 2 years 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 ---
Updated by Kristof Provost over 2 years 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().
Updated by Kristof Provost over 2 years ago
https://gitlab.netgate.com/pfSense/FreeBSD-src/-/merge_requests/85
I'll merge that, and merge the change to plus-devel-12 as well.
Updated by Kristof Provost over 2 years ago
- Status changed from New to Feedback
This will be fixed in the next snapshot.
Updated by Marcos M over 2 years ago
Tested on 22.05.b.20220517.1621
, port mapping is now created and no panic is triggered.
Updated by Steve Wheeler over 2 years 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 -> 192.168.206.10 port 55555 [ Evaluations: 10 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 83821 State Creations: 0 ]
Tested:
22.05-BETA (amd64) built on Tue May 17 16:41:01 UTC 2022 FreeBSD 12.3-STABLE
Updated by Jim Pingle over 2 years ago
- Release Notes changed from Default to Force Exclusion
Not a problem in a release, so excluding from release notes.