[BUG] net: bridge: failed attach leaks slave promiscuity

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

br_add_if() can acquire a promiscuity reference for the new slave before
a later error sends it to the err6 unwind.  nbp_vlan_init() allocation
failure is one reachable point.

The successful prefix does:

  list_add_rcu(&p->list, &br->port_list)
  nbp_update_port_count()
  br_manage_promisc()
  br_port_set_promisc()
  dev_set_promiscuity(dev, +1)

The err6 path then removes the port from port_list before the remaining
nbp_update_port_count() call, so the removal path cannot see or clear
the port's promiscuous state.  The later dev_set_allmulti(dev, -1)
balances only the separate allmulti reference.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1.  Failslab forced an
allocation failure in the first nbp_vlan_init() allocation.  The failed
attach returned an error and left no master, but the slave's
IFLA_PROMISCUITY grew 0 -> 1 -> 2 -> 3 across repeated failures.

A later successful attach/detach moved the counter 3 -> 4 -> 3.  Another
successful cycle returned to 3, proving the first attach/detach pair was
balanced and could not remove the references leaked by failed attaches.

The error path must explicitly release the promiscuous reference before
unlinking the port, or reorder teardown so the normal promiscuous update
still includes the failing port.

The PoC, fault-injection runner, and complete program/serial logs are
available on request.

This was found with a multi-agent workflow; the state
leak was reproduced under KASAN+UBSAN (no crash is expected).

Thanks,
Cheng Yongkang