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.
