pfSense

Update: this issue has been recurring across our pfSense Plus VPN concentrator fleet. Several occurrences to date on more than one host; the original report covered the first occurrence we caught with a usable core dump, and we have now captured a second.

Recurrence pattern¶

• Multiple crashes observed across two pfSense Plus VPN concentrators in our fleet (both 25.11.1-RELEASE, both strongSwan 6.0.3). Earlier occurrences were detected reactively (tunnels down, peer reports) without a captured core; only two have full cores so far.
• Most recent captured core: 2026-05-16, on a different concentrator than the host in the original report.
• The peer involved in the most recent crash is not the same peer as in the original report — different vendor, different site. The trigger is not specific to a single peer's IKE stack.

Same crash signature in every case we've inspected: SIGBUS caught by charon's in-process signal handler, charon then sends itself SIGABRT, the {{ipsec.log}} stack trace bottoms out in the CHILD_SA rekey/delete path of {{libcharon}}.

Core dump analysis (most recent occurrence)¶

Inspected the most recent core with gdb against the stripped {{libcharon.so.0}} from pfSense Plus 25.11.1. Sysroot assembled from base libraries off the affected host. (Local gdb 17.1 on a different platform read the FreeBSD amd64 core fine — cross-platform core inspection works for this purpose.)

Fault location: identical to the original core, byte-for-byte.

• Faulting RIP: same offset within {{libcharon.so.0}} as the first core ({{libcharon+0x7786a}})
• Faulting instruction: indirect virtual call through the CHILD_SA at vtable slot {{0x168}}
• Immediately following call in the emitted code: {{child_rekey_conclude_rekeying@plt}}

Sanitized disassembly of the fault region (no customer-identifying state — this is just the compiled instruction sequence, identical between cores):

mov    %rbx,%rdi                  ; rdi = CHILD_SA pointer
xor    %esi,%esi
call   *0x168(%rbx)               ; *** FAULT ***  (indirect call through vtable)
mov    %r12,%rdi
mov    %rbx,%rsi
call   child_rekey_conclude_rekeying@plt

Use-after-free confirmed at the byte level. In the most recent core, the memory pointed to by {{%rbx}} (the CHILD_SA the fault is calling a method on) is filled with {{0x5a}} — the jemalloc free-poison pattern. The vtable slot at {{*0x168(%rbx)}} therefore reads garbage, the call jumps to unmapped memory, and SIGBUS fires. The surviving sibling object passed as the second argument to {{child_rekey_conclude_rekeying}} is intact and still has a normal vtable.

This is exactly the failure mode strongSwan #2944 / #2945 describes: "a peer initiates two sequential rekeyings for the same Child SA... When the first replacement gets deleted, the code attempts to finalize rekeying with an already-destroyed original SA, causing the crash." The destroyed-original SA in our most recent core is the one filled with poison bytes; the not-yet-destroyed replacement is still live next to it.

What this changes for prioritization¶

• Multiple recurrences across more than one host, more than one peer — this is reachable from at least two independent IKEv2 implementations under normal operation.
• Will continue to fire across this fleet until strongSwan 6.0.4+ ships in the pfSense Plus packages.
• No peer-side mitigation is available — there is nothing wrong with what the peers sent; the upstream code path is incorrect.

We are operating under a plus-target of 26.03.1 per Christian's earlier note, which is appreciated. If there is any opportunity to ship the strongSwan 6.0.4 (or later) bump on the 25.11.x train as well, that would close the window faster for sites that haven't moved to 26.x yet.

Available on request¶

Happy to provide via a non-public channel:

• Sanitized full disassembly of the fault region (both cores)
• Sanitized 17-thread backtrace from each captured core
• Approximate timing of recurring occurrences
• Other host-side state that may help — e.g. swanctl version output, kernel ring snippets, build provenance for the strongSwan package as installed

Core files themselves contain peer-identifying data (preshared keys, IP addresses, identities) and will not be attached.

We have picked 2.6.20 back to the 25.11.1 repo.