Re: [PATCH 1/2] netfilter: bridge: refragment packets with a vlan tag moved by the bridge

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Oct 19, 2026 at 05:54:03PM -0700, Laveesh Bansal wrote:
> With vlan_filtering enabled, br_allowed_ingress() moves the vlan tag back
> into the packet when its protocol differs from the bridge's vlan_protocol,
> an 802.1Q tag on an 802.1ad bridge for instance, and sets skb->protocol to
> the vlan ethertype. That happens after the NF_BR_PRE_ROUTING hooks.
> 
> Bridge conntrack has already defragmented the packet by then, based on the
> original protocol. In postrouting nf_ct_bridge_refrag() finds a vlan
> ethertype it cannot fragment, warns and drops the packet:
> 
>  WARNING: net/bridge/netfilter/nf_conntrack_bridge.c:361 at nf_ct_bridge_post
>  Call trace:
>   nf_ct_bridge_post
>   nf_hook_slow
>   br_forward_finish
>   __br_forward
>   deliver_clone
>   br_flood
>   br_handle_frame_finish
>   br_handle_frame
> 
> The warning is the smaller problem. Every fragmented IPv4 or IPv6 packet
> that crosses such a bridge is dropped while unfragmented traffic is fine,
> so it looks like an MTU issue. And anyone who can send fragments into a
> port of such a bridge can trigger the warning, which takes the machine
> down with panic_on_warn.
> 
> Look past the vlan tag in nf_ct_bridge_refrag(): remember it, pull it,
> fragment as before and push it back onto each fragment in
> nf_ct_bridge_frag_restore(), together with the outer protocol, so that
> br_dev_queue_push_xmit() sees the fragments like any other tagged frame.
> The protocol behind the tag comes from the packet, so check it against the
> header before fragmenting.
> 
> Removing the WARN_ON_ONCE() would only hide the problem, the packets would
> still be dropped. Not tracking these frames in nf_ct_bridge_pre() instead
> would change what is tracked today for unfragmented traffic, and would have
> to duplicate the decision that br_allowed_ingress() makes later.

Yes, but let's just fix this by turning this into a
DEBUG_NET_WARN_ON_ONCE(1) and let the packet be dropped.

Then, we can follow up to fill the gap for this feature in in nf-next.