CVE-2025-38470: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime

In the Linux kernel, the following vulnerability has been resolved:

net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime

Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme.

The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running:

# ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1

When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1].

Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bugon[2] will be triggered by unregistervlandev() for refcount imbalance if toggling filtering during runtime:

$ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0

Root cause is as below: step1: add vlan0 for realdev, such as bond, team. registervlandev vlanvidadd(realdev,htons(ETHP8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable realdev step3: change filter from 0 to 1 vlandeviceevent vlanfilterpushvids ndovlanrxaddvid //No refcnt added to realdev vlan0 step4: realdev down vlandeviceevent vlanviddel(dev, htons(ETHP8021Q), 0); //refcnt=0 vlaninforcufree //free vlan0 step5: delete vlan0 unregistervlandev BUGON(!vlaninfo); //vlaninfo is null

Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEVUP and based on that decide whether it should be deleted upon NETDEVDOWN, regardless of the state of the "rx-vlan-filter" feature.

[1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): kmalloccachenoprof+0x2b5/0x340 vlanvidadd+0x434/0x940 vlandeviceevent.cold+0x75/0xa8 notifiercallchain+0xca/0x150 devnotifyflags+0xe3/0x250 rtnlconfigurelink+0x193/0x260 rtnlnewlinkcreate+0x383/0x8e0 rtnlnewlink+0x22c/0xa40 rtnlnewlink+0x627/0xb00 rtnetlinkrcvmsg+0x6fb/0xb70 netlinkrcvskb+0x11f/0x350 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 socksendmsg+0xc1/0x150 syssendmsg+0x5aa/0x7b0 syssendmsg+0xfc/0x180

[2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregistervlandev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated---