diff options
| author | Cheng Yongkang <teel4res@gmail.com> | 2026-10-31 21:48:40 -0700 |
|---|---|---|
| committer | Paolo Abeni <pabeni@redhat.com> | 2026-11-05 12:14:28 +0100 |
| commit | 37dfd0efbfffc20a57e41c2eb349ac49b1ca1ff8 (patch) | |
| tree | 93660a34fd000cd14f4a2e6a0e1a9b6c5c89718b /include/uapi/linux/devlink.h | |
| parent | 6d9b7c85af57305ec2bd5907124478867edcc60b (diff) | |
net: bridge: disable MRP ports before the FDB flush in del_nbp()
del_nbp() flushes the port's FDB entries before it unregisters the RX
handler. For a normal port, br_stp_disable_port() moves the port to
BR_STATE_DISABLED before this cleanup.
That does not hold for an MRP ring port. br_set_state() ignores state
changes while BR_MRP_AWARE_BIT is set, so br_stp_disable_port() leaves
the port state alone. br_mrp_port_del() then restores forwarding when
the bridge is up before clearing the bit. A frame received between
br_fdb_cleanup_by_dst() and netdev_rx_handler_unregister() can therefore
create a new FDB entry referencing the dying port. Nothing removes that
entry before destroy_nbp_rcu() frees the port, so a later frame to the
learned MAC can be forwarded through the freed port.
Remove the MRP and CFM instances before disabling the port, so that
br_stp_disable_port() actually transitions it to BR_STATE_DISABLED.
With CONFIG_BRIDGE_VLAN_FILTERING=y, synchronize_net() in
nbp_vlan_group_unpublish() also drains receive paths that could still
learn with the old state before the final FDB cleanup.
Found through an LLM-assisted source code analysis workflow and
reproduced on net with KASAN and CONFIG_BRIDGE_VLAN_FILTERING=y in QEMU.
A diagnostic switchdev module accepts MRP objects and delays the
NETDEV_CHANGEUPPER callback for 1.5 s, holding del_nbp() after the FDB
cleanup and before RX handler removal. The reproducer floods the MRP
port with rotating source MACs, waits for the port's RCU callback
through the module's rcu_barrier(), then sends frames to those MACs
from another port. The unpatched kernel reports:
BUG: KASAN: slab-use-after-free in br_forward+0xb1/0x820
Call Trace:
<IRQ>
br_forward+0xb1/0x820
br_handle_frame_finish+0x148b/0x1e50
br_handle_frame+0x90a/0x15c0
With this patch, three runs of six cycles each reach the delay without
a KASAN report.
Fixes: 6536993371fa ("bridge: mrp: Integrate MRP into the bridge")
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/netdev/20261012123051.GA714215@shredder/
Closes: https://lore.kernel.org/netdev/20261022090431.3641707-1-teel4res@gmail.com/
Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261101044840.1595584-1-1020691186@qq.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'include/uapi/linux/devlink.h')
0 files changed, 0 insertions, 0 deletions
