CVE-2022-49812 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
bridge: switchdev: Fix memory leaks when changing VLAN protocol
The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag.
To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag.
When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol.
In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted.
Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev.
[1]
unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750
[<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920
[<000000000632b56f>] br_changelink+0x3d6/0x13f0
[<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0
[<00000000f6276baf>] rtnl_newlink+0x5f/0x90
[<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00
[<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340
[<0000000010588814>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40
[<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0
[<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0
[<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0
[<00000000684f7e25>] __sys_sendmsg+0xab/0x130
[<000000004538b104>] do_syscall_64+0x3d/0x90
[<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/07/2025
The vulnerability described in CVE-2022-49812 resides within the Linux kernel's bridge driver implementation, specifically concerning the handling of VLAN protocol changes when hardware offloading is enabled through switchdev. This issue manifests as memory leaks during dynamic VLAN protocol transitions, creating potential stability and resource exhaustion concerns for systems relying on network virtualization and hardware offloading capabilities. The root cause stems from improper handling of VLAN state management when transitioning between different VLAN protocol implementations, particularly when the bridge driver attempts to interact with both switchdev and 8021q drivers simultaneously during protocol changes.
The technical flaw occurs when the bridge driver processes VLAN protocol changes through the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL attribute notification mechanism. During this process, the driver attempts to invoke the 8021q driver to both add and delete VLANs with the new and old protocols respectively. However, this behavior becomes problematic when VLANs have already been offloaded to hardware via switchdev, as indicated by the BR_VLFLAG_ADDED_BY_SWITCHDEV flag. The redundant and erroneous interaction with the 8021q driver for hardware-offloaded VLANs leads to memory allocation inconsistencies and ultimately results in unreferenced objects that persist in kernel memory. The memory leak pattern identified in the backtrace shows objects with size 256 being allocated and subsequently leaked, with the stack trace indicating the issue originates from vlan_vid_add function within the VLAN subsystem.
This vulnerability directly impacts system stability and resource utilization, particularly in environments where network bridges frequently change VLAN protocols or where hardware offloading is actively used. The memory leaks accumulate over time and can lead to system performance degradation, potential out-of-memory conditions, and increased kernel memory pressure. The operational impact is significant for data center and cloud environments where network virtualization and hardware offloading are common practices. From a security perspective, while this vulnerability does not directly expose a remote attack vector, it can contribute to system instability that may be exploited by adversaries to cause denial-of-service conditions or potentially escalate privileges through resource exhaustion attacks.
The fix implemented addresses the core issue by preventing the 8021q driver from being invoked for VLANs that have been marked with the BR_VLFLAG_ADDED_BY_SWITCHDEV flag, effectively eliminating the redundant operations that cause the memory leaks. This solution aligns with the principle of proper resource management and state consistency within kernel subsystems. The mitigation strategy follows established security practices for preventing memory leaks in kernel code, particularly in networking drivers where state transitions are frequent and complex. The fix ensures that hardware-offloaded VLANs maintain their state correctly without unnecessary interactions with software VLAN handling components, thereby preserving system resources and preventing the accumulation of unreferenced kernel objects. This approach also aligns with the ATT&CK framework's concept of privilege escalation through resource exhaustion and system stability compromise, as it prevents potential indirect exploitation pathways that could arise from persistent memory leaks in critical kernel subsystems. The solution represents a targeted fix that maintains backward compatibility while addressing the specific interaction pattern that caused the vulnerability, demonstrating proper adherence to kernel development practices and security hardening principles.