Re: Panic: Memory modified after free

On Wed, Jul 22, 2026 at 2:56 PM Steve Kargl <kargls@comcast.net> wrote:
>
> On 7/22/26 12:16, Enji Cooper (yaneurabeya) wrote:
> >
> >> cpuid = 7
> >> time = 1784737711
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01498028f0
> >> vpanic() at vpanic+0x136/frame 0xfffffe0149802a20
> >> panic() at panic+0x43/frame 0xfffffe0149802a80
> >> trash_ctor() at trash_ctor+0x74/frame 0xfffffe0149802a90
> >> item_ctor() at item_ctor+0x59/frame 0xfffffe0149802ae0
> >> mc_get() at mc_get+0x14c/frame 0xfffffe0149802b40
> >> mc_uiotomc() at mc_uiotomc+0x8d/frame 0xfffffe0149802b80
> >> uipc_sosend_stream_or_seqpacket() at uipc_sosend_stream_or_seqpacket+0x13e/frame 0xfffffe0149802c60
> >> sousrsend() at sousrsend+0x79/frame 0xfffffe0149802cc0
> >> kern_sendit() at kern_sendit+0x1be/frame 0xfffffe0149802d50
> >> sendit() at sendit+0x1ab/frame 0xfffffe0149802da0
> >> sys_sendmsg() at sys_sendmsg+0x5b/frame 0xfffffe0149802e00
> >> amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe0149802f30
> >> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0149802f30
> >> --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x39727abfe3ca, rsp = 0x397275edc298, rbp = 0x397275edc2c0 ---
> >> KDB: enter: panic
> >>
> >> I have crash dump and can upload to kargl@freefall if needed.
> >
> >       Hm. An mbuf-related use-after-free.. I don’t see anything obviously wrong with f2202ab5abda7fb09538a1ceda77569b67d83084, but that’s the only recent commit made to the mbuf subsystem in the past few weeks. Can you try reverting that commit and reproing the issue?
>
> In looking at the core.txt.2, I realized that I had not updated
> openvpn when I updated world.  As it initializes a tun device
> and tears it down when I stop openvpn, I updated it to possibly
> get it in-sync with world.  So, I may not be able to reproduce
> it.  I'll keep the dump around if anyone needs/wants it.
>
> --
> steve

As Enji said, it's apparently a modification of a free mbuf.  It's
from the 256 byte mbuf zone, at byte offset 8 from the beginning of
the object.  0xdeadc0dedeadc0de ^ 0xdeadc0dedead40ce = 0x8010.  That's
strange, in a 256-byte mbuf that offset is a pointer, so that doesn't
look like a way in which it would normally be modified.  So maybe the
modification didn't come from someone that thought it was an mbuf.

Which network drivers do you use?

If you do upload the dump and kernel and symbols, I may take a peek.
I would suggest looking at the rest of the 256-byte region and
thereabouts to see if there are any other clues.  One could also scrub
memory for pointers to the region.

Ryan