Bug #13338


OpenVPN DCO panics with short UDP packets

Added by Marcos M almost 2 years ago. Updated over 1 year ago.

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


Estimated time:
Release Notes:
Affected Plus Version:
Affected Architecture:


If a UDP packet directed towards an active OpenVPN socket is received which is too short to contain an OpenVPN header, a panic is triggered.

db:0:kdb.enter.default>  show pcpu
cpuid        = 0
dynamic pcpu = 0x9a9140
curthread    = 0xfffff800046fd000: pid 0 tid 100079 "if_io_tqg_0" 
curpcb       = 0xfffff800046fd5a0
fpcurthread  = none
idlethread   = 0xfffff80004662000: tid 100003 "idle: cpu0" 
curpmap      = 0xffffffff83690da8
tssp         = 0xffffffff8371aea0
commontssp   = 0xffffffff8371aea0
rsp0         = 0xfffffe00005a7cc0
kcr3         = 0x8000000003d1b003
ucr3         = 0xffffffffffffffff
scr3         = 0x54cfca9f4
gs32p        = 0xffffffff837216b8
ldt          = 0xffffffff837216f8
tss          = 0xffffffff837216e8
tlb gen      = 485921
curvnet      = 0xfffff80004108b40
db:0:kdb.enter.default>  bt
Tracing pid 0 tid 100079 td 0xfffff800046fd000
kdb_enter() at kdb_enter+0x37/frame 0xfffffe00005a7340
vpanic() at vpanic+0x194/frame 0xfffffe00005a7390
panic() at panic+0x43/frame 0xfffffe00005a73f0
trap_fatal() at trap_fatal+0x38f/frame 0xfffffe00005a7450
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00005a74b0
calltrap() at calltrap+0x8/frame 0xfffffe00005a74b0
--- trap 0xc, rip = 0xffffffff80e14d74, rsp = 0xfffffe00005a7580, rbp = 0xfffffe00005a75b0 ---
m_copydata() at m_copydata+0x74/frame 0xfffffe00005a75b0
ovpn_udp_input() at ovpn_udp_input+0x6c/frame 0xfffffe00005a7650
udp_append() at udp_append+0x5b/frame 0xfffffe00005a76d0
udp_input() at udp_input+0x926/frame 0xfffffe00005a77c0
ip_input() at ip_input+0x16e/frame 0xfffffe00005a7870
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe00005a78c0
ether_demux() at ether_demux+0x16a/frame 0xfffffe00005a78f0
ether_nh_input() at ether_nh_input+0x33b/frame 0xfffffe00005a7950
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe00005a79a0
ether_input() at ether_input+0x89/frame 0xfffffe00005a7a00
iflib_rxeof() at iflib_rxeof+0xaa6/frame 0xfffffe00005a7ae0
_task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe00005a7b20
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x121/frame 0xfffffe00005a7b80
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xd2/frame 0xfffffe00005a7bb0
fork_exit() at fork_exit+0x7e/frame 0xfffffe00005a7bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00005a7bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Actions #1

Updated by Kristof Provost almost 2 years ago

That looks to be the result of a short UDP packet. Short enough that it doesn't contain an openvpn header. fixes that.

Actions #2

Updated by Marcos M almost 2 years ago

  • Subject changed from OpenVPN DCO panic to OpenVPN DCO panics with short UDP packets
  • Description updated (diff)
  • Status changed from New to Pull Request Review
Actions #3

Updated by Steve Wheeler almost 2 years ago

  • Status changed from Pull Request Review to Feedback

This is now merged.

Actions #4

Updated by Georgiy Tyutyunnik almost 2 years ago

Tested on 22.05, was able to reproduce

tested on
Version 22.09-DEVELOPMENT (amd64)
built on Fri Jul 08 06:14:39 UTC 2022

this version fixes the bug, firewall no longer crashes

Actions #5

Updated by Kris Phillips over 1 year ago

This can be marked as Resolved since we have tested the fix and confirmed it's resolution.

Actions #6

Updated by Jim Pingle over 1 year ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF