kernel/git/stable/linux.git/net/bridge, branch master

net: bridge: mcast: fix use-after-free of a master VLAN's multicast context

2026-08-27T19:35:03+00:00

br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context. Fixes: 7b54aaaf53cb ("net: bridge: multicast: add vlan state initialization and control") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/D400F6C7-543A-4B79-9E5B-D1D8974DE5C9@doyensec.com Signed-off-by: Jakub Kicinski

net: bridge: arp/nd proxy: fix reading neigh ha

2026-08-20T21:23:06+00:00

Currently neigh ha address is read directly, but that can result in torn/partial reads if the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address. Fixes: 057658cb33fb ("bridge: suppress arp pkts on BR_NEIGH_SUPPRESS ports") Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Petr Machata Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260818150756.890025-2-razor@blackwall.org Signed-off-by: Jakub Kicinski

net: bridge: Reject descending VLAN tunnel ranges

2026-08-20T18:32:44+00:00

A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 94339443686b ("net: bridge: notify on vlan tunnel changes done via the old api") Signed-off-by: Ruoyu Wang Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260814134053.1387275-1-ruoyuw560@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-08-18T17:42:41+00:00

Merge in late fixes in preparation for the net-next PR. Conflicts: drivers/dpll/dpll_core.c drivers/dpll/dpll_netlink.c 33f016b23a219 ("dpll: fix NULL deref in dpll_device_ops() during teardown race") b1d0c412088e3 ("dpll: add STATE_CONNECTED_OVERRIDE pin capability") https://lore.kernel.org/aoR9YYY2P5--3x0N@sirena.org.uk https://lore.kernel.org/aoR9VmKllVGwmQn_@sirena.org.uk No adjacent changes. Signed-off-by: Jakub Kicinski

net: bridge: vlan: fix inverted default vlan notification

2026-08-18T01:27:14+00:00

A notification should be emitted only when the vlan delete was successful and not otherwise. The proper check is if br/nbp_vlan_delete returned 0. Fixes: f545923b4a6b ("net: bridge: vlan: notify on vlan add/delete/change flags") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260814141640.64958-1-razor@blackwall.org Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-08-13T18:00:14+00:00

Cross-merge networking fixes after downstream PR (net-7.2-rc8). No conflicts. Adjacent changes: drivers/net/ethernet/wangxun/ngbe/ngbe_main.c 5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling") d661abdc30c2 ("net: ngbe: correct misleading interrupt comment") drivers/net/ipvlan/ipvlan_main.c e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") 00a40d809207 ("ipvlan: Support per-netns netdev unregistration.") Signed-off-by: Jakub Kicinski

netfilter: bridge: release template ct on non-IP path

2026-08-10T18:14:01+00:00

A bridge nftables ct zone set rule can attach a conntrack template to an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6 EtherTypes, nf_ct_bridge_pre() currently overwrites skb->_nfct with IP_CT_UNTRACKED without releasing the existing template reference. That makes the per-cpu template, and any temporary templates allocated for concurrent use, unreachable and leaks memory until the host runs out of slab. Reset the skb conntrack state before marking the frame untracked so the existing template reference is dropped on the non-IP path. Fixes: 3c171f496ef5 ("netfilter: bridge: add connection tracking system") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Pablo Neira Ayuso

bridge: Use ndisc_parse_options() to parse ND options in br_nd_send()

2026-08-07T23:32:46+00:00

Replace the manual ND option parsing loop in br_nd_send() with ndisc_parse_options(), which provides proper validation and avoids the class of bugs that were fixed by commit 53fc685243bd ("bridge: Avoid infinite loop when suppressing NS messages with invalid options") and commit 850837965af1 ("bridge: br_nd_send: validate ND option lengths"). Use ndisc_opt_addr_data() to extract the source link-layer address from the parsed options, which correctly validates the option length for the underlying device type. Export ndisc_parse_options() so that it can be resolved from the bridge when it is built as a module (CONFIG_BRIDGE=m); otherwise modpost fails with an undefined symbol. Reviewed-by: Petr Machata Acked-by: Nikolay Aleksandrov Signed-off-by: Danielle Ratson Link: https://patch.msgid.link/20260803112505.613873-6-danieller@nvidia.com Signed-off-by: Jakub Kicinski

bridge: Linearize skb once the ND message type is validated

2026-08-07T23:32:46+00:00

br_nd_send() parses ND options from ns->opt[] and therefore needs the skb to be linear. Commit a01aee7cafc5 ("bridge: br_nd_send: linearize skb before parsing ND options") ensured that by linearizing inside br_nd_send() itself. Move the linearization up into br_is_nd_neigh_msg(), right after ndisc_check_ns_na() has validated the message as an NS/NA. This makes a linear buffer a property of every recognized ND message, so that this and any future ND message handling operate on a linear skb and cannot reintroduce that class of bug by forgetting to linearize. Since the skb is now linear by the time br_nd_send() runs, drop the linearization there and derive ns from the transport header set by ndisc_check_ns_na(), instead of recomputing it from the network header. If linearization fails under memory pressure, br_is_nd_neigh_msg() returns NULL and the packet falls back to normal forwarding rather than being suppressed. Reviewed-by: Petr Machata Signed-off-by: Danielle Ratson Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260803112505.613873-5-danieller@nvidia.com Signed-off-by: Jakub Kicinski

bridge: Validate NS/NA messages using ndisc_check_ns_na()

2026-08-07T23:32:46+00:00

The bridge performs neighbor suppression by snooping NS/NA messages, but previously only checked the ICMPv6 type and code. This leaves it open to acting on malformed or spoofed packets that any RFC-compliant node should reject. Wire br_is_nd_neigh_msg() into the new ndisc_check_ns_na() helper, which enforces the full RFC 4861 section 7.1.1/7.1.2 receive validation: hop limit of 255, valid checksum, correct code, and type-specific rules (NS target not multicast; NA solicited flag clear for multicast destinations). MLD messages are already validated by ipv6_mc_check_mld() before the bridge acts on them; this brings NS/NA to the same standard. As a side effect, the skb parameter of br_is_nd_neigh_msg() changes from const to non-const, since ndisc_check_ns_na() may reallocate the skb head via pskb_may_pull() and sets the transport header. The returned pointer is now derived from skb_transport_header() rather than a direct cast. Reviewed-by: Petr Machata Acked-by: Nikolay Aleksandrov Signed-off-by: Danielle Ratson Link: https://patch.msgid.link/20260803112505.613873-4-danieller@nvidia.com Signed-off-by: Jakub Kicinski