[BUG] net: bridge: failed VLAN tunnel update suppresses state notification

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

br_vlan_process_one_opts() commits BRIDGE_VLANDB_ENTRY_STATE before it
attempts BRIDGE_VLANDB_ENTRY_TUNNEL_INFO.  If tunnel insertion fails,
the option loop exits before that VID's changed flag is included in the
notification range.

The new VLAN state remains active, the request returns an error, and no
RTM_NEWVLAN reports the state transition.  This makes netlink listeners
disagree with the kernel VLAN database.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1.  A range request for
VID 10..12 set state BLOCKING and tunnel IDs starting at 100.  VID 11's
tunnel ID 101 collided with an existing mapping:

  request result:          -EEXIST
  VID 11 kernel state:     BLOCKING
  VID 11 tunnel mapping:   absent
  VID 12 kernel state:     FORWARDING
  RTM_NEWVLAN for VID 11:  absent
  RTM_NEWLINK for the port: absent

The listener was opened after setup and pre-existing multicast events
were drained.

Correct behavior is per-VID atomicity: validate/prepare all options
that can fail before committing state, and roll back any earlier
successful option writes on failure.  If partial commits are
intentional, the failing VID must still be notified before returning
the error.

CVE-2026-90114 covers a different defect in the same batched range code
(descending ranges and an uninitialized error value).  I found no
matching fix for this state/notification loss.

The PoC and two independent logs are available on request.

This was found with a multi-agent workflow; the exact
notification/state divergence was reproduced in QEMU/KVM.

Thanks,
Cheng Yongkang