[Bug 268246] crash and panic using pfsync on 13.1-RELEASE

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246

--- Comment #22 from Kristof Provost <kp@freebsd.org> ---
(In reply to jjasen from comment #21)
Okay, so I think I see what's going on here.

Essentially what's happening here is that we need to know what vnet we're in
because we're in a callout and those don't belong to specific vnets. We got
from that the mbuf's received interface, but that's not set for locally
originated traffic, so we panic dereferencing a NULL pointer.

Happily we also have a pointer to the pfsync interface, and we can just get the
vnet pointer from there.

I've not been able to meaningfully test this myself, because today there are
not a lot of internets around where I'm staying.

This patch is against main, but should just apply on stable/13 as well.

diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
index a2baf477873e..05c80ae725ea 100644
--- a/sys/netpfil/pf/if_pfsync.c
+++ b/sys/netpfil/pf/if_pfsync.c
@@ -1819,8 +1819,11 @@ pfsync_defer_tmo(void *arg)

        PFSYNC_BUCKET_LOCK_ASSERT(b);

+    if (sc->sc_sync_if == NULL)
+        return;
+
        NET_EPOCH_ENTER(et);
-       CURVNET_SET(m->m_pkthdr.rcvif->if_vnet);
+       CURVNET_SET(sc->sc_sync_if->if_vnet);

        TAILQ_REMOVE(&b->b_deferrals, pd, pd_entry);
        b->b_deferred--;

The other issue I still don't understand, but once you've tested the above
patch it'd also be useful to test pfsync without defer mode. I wonder if the
problem is related to that.

-- 
You are receiving this mail because:
You are the assignee for the bug.