Hi all, br_vlan_rtm_process_one() reuses the VLAN operation command map for the RTNLGRP_LINK notification type. A successful RTM_NEWVLAN therefore multicasts RTM_SETLINK, while RTM_DELVLAN multicasts RTM_DELLINK even though the target netdevice still exists. br_fill_ifinfo() also omits IFLA_PROTINFO unless the event is RTM_NEWLINK.
Observed on Linux v7.3, commit 08ab31164c55f20c7a2653de3186ae333470e2c1: RTM_NEWVLAN -> ACK 0 link notification nlmsg_type=19 (RTM_SETLINK) IFLA_PROTINFO absent RTM_DELVLAN -> ACK 0 link notification nlmsg_type=17 (RTM_DELLINK) IFLA_PROTINFO absent target port still exists after the DELVLAN The kernel's dynamic-debug output independently confirmed br_fill_ifinfo event 19 and event 17 for the port. The request handlers need RTM_SETLINK/RTM_DELLINK operation semantics, but successful VLAN changes should emit RTM_NEWLINK, matching the older br_setlink()/br_dellink() notification paths. The 2015 notification compatibility fix established that ABI, and the later RTM VLAN path regressed it. I found no matching upstream fix or CVE. The self-contained PoC and full serial log are available on request. This was found with a multi-agent workflow; both event types were reproduced in QEMU. Thanks, Cheng Yongkang
