CVE-2026-46153

Technical summary

The vulnerability resides in vlan_dev_set_egress_priority() within the Linux kernel's 8021q VLAN driver. The function manages a hash table of egress priority mappings that translate socket buffer (skb) priorities to VLAN priority codes. Previously, when a mapping was cleared (vlan_prio set to 0), the kernel removed the mapping data but retained the node in the hash table as a tombstone entry. Repeated set/clear cycles with different skb priorities would accumulate these stale nodes indefinitely. With RCU (Read-Copy-Update) synchronization now protecting the egress mapping lists, the kernel can safely unlink cleared nodes and free them after an RCU grace period, preventing the accumulation. This resolves the memory leak without introducing synchronization races.

Business impact

Memory leaks in network drivers degrade system stability and availability. Systems running affected Linux kernel versions with active VLAN QoS configuration will gradually consume more memory as mappings are repeatedly set and cleared—a common pattern in dynamic network provisioning environments. Over weeks or months, this exhaustion can force unplanned reboots or service interruptions. For organizations relying on VLAN-based traffic prioritization in data center or cloud environments, this could affect availability and require premature system maintenance cycles.

Affected systems

All Linux kernel versions containing the vulnerable vlan_dev_set_egress_priority() implementation are affected. This includes recent stable and long-term support (LTS) kernel branches. The vulnerability is particularly relevant to systems actively using VLAN interfaces with QoS egress priority mappings, including cloud platforms, container hosts, and data center infrastructure. Verify the specific kernel versions running in your environment against the Linux kernel security advisory for the precise affected range.

Exploitability

This vulnerability requires local access and the ability to configure VLAN network interfaces—specifically to set and clear egress QoS priority mappings. An unprivileged user cannot easily trigger this on a shared system; however, administrators, containerized workloads with network privileges, or local root users can induce the leak. The memory exhaustion is a denial-of-service condition rather than a data breach or privilege escalation vector. Exploitation requires intentional or malicious repeated reconfiguration, making this lower priority than remote or privilege-escalation vulnerabilities.

Remediation

Apply the Linux kernel security patch that implements proper deletion of cleared egress QoS mappings. Verify the exact patched kernel version applicable to your distribution (verify against the vendor advisory). Systems should prioritize updating to a kernel version that includes the fix, particularly those running services that dynamically manage VLAN QoS rules. In environments where kernel updates are infrequent, monitor memory usage on affected hosts to detect early signs of the leak.

Patch guidance

Consult your Linux distribution's security advisory for the specific kernel version containing this fix. Major distributions (Red Hat, Ubuntu, Debian, SUSE, etc.) will backport this patch to their supported kernel branches. Apply patches according to your organization's change management and system restart policies. Kernel updates typically require a reboot to take effect. Test patches in non-production environments first. Document which systems were running vulnerable versions prior to patching.

Detection guidance

Monitor kernel memory usage trends on systems with active VLAN interfaces, particularly memory allocated to network subsystem structures. Track the number of cleared QoS mappings or monitor the hash table size via kernel debug interfaces. Long-term memory growth without corresponding workload increase, especially on systems repeatedly reconfiguring VLAN QoS rules, may indicate this leak. Automated monitoring tools should alert on sustained memory pressure correlated with VLAN configuration changes. System administrators should review VLAN configuration scripts or orchestration tools that dynamically adjust QoS mappings.

Why prioritize this

While this is a local, limited-impact memory leak rather than a remote code execution vulnerability, it warrants timely remediation because memory exhaustion can degrade availability in production environments. The MEDIUM CVSS score (5.5) reflects the local-access requirement and limited attack surface. Priority should be elevated for systems with frequent VLAN QoS reconfiguration, data center infrastructure, and long-running services where memory leaks compound. Organizations using container orchestration or software-defined networking with dynamic QoS tuning should prioritize patching sooner.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects: local attack vector (AV:L) since interactive shell or privileged access is required; low complexity (AC:L) to trigger the leak; low privilege requirements (PR:L) to reconfigure network interfaces; no user interaction needed (UI:N); and high availability impact (A:H) from memory exhaustion denial-of-service. There is no confidentiality or integrity impact. The score appropriately weights this as a local availability concern rather than a critical threat, but the practical impact on long-running infrastructure justifies prompt attention.

Frequently asked questions