[BUG] net: bridge: VLAN operations emit wrong link event types

[Cheng Yongkang <teel4res@gmail.com>]

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