On 5/20/2026 3:20 AM, Florian Westphal wrote: > Ren Wei <[email protected]> wrote: >> From: Haoze Xie <[email protected]> >> >> The bridge netfilter fake rtable is currently embedded in struct >> net_bridge even though packets can keep using it after bridge teardown. > > How? Please elaborate a bit, it is unexpected. >
The fake rtable is attached to bridged skbs in the br_netfilter prerouting restore path via bridge_parent_rtable() + skb_dst_set_noref(). If such a packet is queued to NFQUEUE, __nf_queue() upgrades that fake dst with skb_dst_force(). From that point on, the queued skb can hold a real dst reference even after bridge teardown starts freeing the backing struct net_bridge storage. When the verdict path later drops or reinjects the skb, dst_release() can still touch that freed fake dst. >> Give the fake rtable its own allocated lifetime and make >> bridge_parent_rtable() return a referenced dst. This way the bridge and >> any packets that still carry the fake dst each hold their own reference, >> so bridge teardown no longer leaves a dangling fake dst behind. > > If we have to do this it would be better to move this kludge into > br_netfilter.c completely and get rid of the fake rtable hack in bridge > for good. > I reworked the patch for v2 to keep the lifetime handling in br_netfilter and to address the issues from the previous version. Instead of adding a separate br_netfilter-private dst lifetime scheme, v2 moves the fake rtable out of struct net_bridge, makes bridge_parent_rtable() return a held dst reference, and switches the callers to skb_dst_set(). To avoid the extra lifetime issues in the previous version, the new fake dst is allocated with rt_dst_alloc(), so it reuses the core IPv4 rtable lifecycle instead of custom br_netfilter dst_ops state. During teardown, br_netfilter first detaches the fake rtable from the bridge, then calls dst_dev_put() before dropping the bridge-owned dst reference. > Please also see various AI comments at > https://sashiko.dev/#/patchset/783d76ac83917b7302c1ec647794bd773bb1875a.1778687139.git.royenheart%40gmail.com > I also went through the Sashiko comments you pointed out. The v2 change is specifically meant to avoid both the bridge-private storage UAF and the follow-up lifetime problems from the previous approach. I will send v2. Thanks, Haoze > [ I would like to zap bridge_netfilter but it seems its too popular ... ]
