Re: if_ovpn: Fatal trap 12: page fault while in kernel mode

On Sat, 27 Jun 2026 13:43:37 -0700
Mark Felder <[email protected]> wrote:

> I did some digging and thought that perhaps this commit was the fix, so
> I updated from 15.0-RELEASE to 15.1-RELEASE:
> https://cgit.freebsd.org/src/commit/sys/net/if_ovpn.c?h=stable/15&id=04a7134c1e92c7752ffdc665f99ae26db70866c0
>
> Unfortunately it did not fix it and I have a feeling that a similar bug
> is lurking elsewhere in the if_ovpn driver. Can someone clarify if this
> is an outstanding bug that needs further investigation or if it's
> potentially already addressed in CURRENT?

It seems that the problem is not in if_ovpn but in pf, that is
the caller of ovpn_output. I have been able to reproduce the
similar crash on 16-CURRENT, so I guess the problem still
exists in CURRENT.

I've posted a review that fixes the crash with a reproducing
test script:
  https://reviews.freebsd.org/D58021

The patch can be applied also for the 15.1-RELEASE src tree, but
I have only tested it on CURRENT.

> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x0
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff81093c4a
> stack pointer           = 0x28:0xfffffe0067d621e0
> frame pointer           = 0x28:0xfffffe0067d621e0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                          = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 12 (irq129: ahci0)
> rdi: fffff801338840ee rsi: 0000000000000000 rdx: 0000000000000267
> rcx: 0000000000000267  r8: 00000000000000c1  r9: fffff800312f7000
> rax: fffff801338840ee rbx: fffff80001eb6200 rbp: fffffe0067d621e0
> r10: fffff80031259000 r11: fffff8003123248c r12: 0000000000000001
> r13: fffff80001de2700 r14: fffff80001de2700 r15: fffff80001b21100
> trap number             = 12
> panic: page fault
> cpuid = 0
> time = 1782496026
> KDB: stack backtrace:
> #0 0xffffffff80bd609d at kdb_backtrace+0x5d
> #1 0xffffffff80b86c06 at vpanic+0x136
> #2 0xffffffff80b86ac3 at panic+0x43
> #3 0xffffffff81097fcd at trap_pfault+0x37d
> #4 0xffffffff8106e568 at calltrap+0x8
> #5 0xffffffff80c265cb at m_unshare+0x36b
> #6 0xffffffff82e9ed7b at ovpn_output+0x2b
> #7 0xffffffff82e4ffdf at pf_route+0x89f
> #8 0xffffffff82e4693a at pf_test+0xd0a
> #9 0xffffffff82e62e6e at pf_check_out+0x2e
> #10 0xffffffff80cda688 at pfil_mbuf_out+0x38
> #11 0xffffffff80d59e2e at ip_output+0xc7e
> #12 0xffffffff8255f92b at rack_output+0x4afb
> #13 0xffffffff80d85602 at tcp_usr_ready+0x182
> #14 0xffffffff80b84da5 at sendfile_iodone+0x115
> #15 0xffffffff80f534df at vnode_pager_generic_getpages_done_async+0x3f
> #16 0xffffffff80c510f1 at bufdone+0x41
> #17 0xffffffff80abd317 at g_io_deliver+0x2a7
> Timeout initializing vt_vga
> Uptime: 1h14m9s

----
KUROSAWA, Takahiro