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
