[BUG] net: bridge: failed offload leaks busy hwdoms and TX refs

[BUG] net: bridge: failed offload leaks busy hwdoms and TX refs

[Cheng Yongkang]

Hi all,

br_add_if() can fail after a switchdev bridge port has partially
offloaded.  For a bond over DSA user ports whose LAG members report
different switch IDs, the first member successfully reserves a
busy_hwdoms bit and increments the tx-forward-offload static key.  The
second member returns -EBUSY, which aborts the upper-device link and
eventually frees the new net_bridge_port.

The br_add_if() error unwind does not call nbp_switchdev_del() for this
partially offloaded port.  The reserved domain and TX static-key
reference remain with no bridge port owner.  Repeated failures consume
BR_HWDOM_MAX domains globally for that bridge.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1:

  before attach:        busy_hwdoms=0x0, key count=0
  after one failure:    busy_hwdoms=0x2, key count=1
  after three failures: busy_hwdoms=0xe, key count=3

After every failed RTM_SETLINK, bond0 had no bridge port and
/sys/class/net/bond0/brport did not exist.  The bridge port list had no
owner for the reserved bits.

The target bridge and DSA code were unchanged.  Because the VM has no
physical DSA driver, an in-tree dsa_loop build was exposed as an
external test module and a second switch ID was supplied through the
normal DSA identity objects.  The reproduced path was:

  br_add_if -> NETDEV_CHANGEUPPER
    -> dsa_user_lag_changeupper
    -> dsa_port_lag_join
    -> dsa_port_bridge_join
    -> switchdev_bridge_port_offload

The failed br_add_if() unwind must fully undo partial bridge switchdev
offload before the port is destroyed.

Candidate BR-030 is a distinct packet-suppression bug caused by a
self-match and hwdom 0; it is not this resource leak.

The module sources, harness, and full logs are available on request.

This was found with AI-assisted source analysis and fuzzing; the exact
resource progression was reproduced in QEMU.

Thanks,
Cheng Yongkang