CVE-2026-46153

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel 802.1Q VLAN implementation. When egress VLAN QoS priority mappings are repeatedly set and then cleared, the kernel previously retained cleared mappings as tombstone entries instead of deleting them. A local user with sufficient privileges to configure VLAN egress QoS mappings can repeatedly create and clear mappings with distinct skb priorities, causing kernel memory to accumulate until the VLAN device is removed or the system experiences memory pressure. The resolved behavior removes cleared mappings and frees them safely after an RCU grace period.

Why it matters to the business

Successful exploitation can degrade or interrupt Linux systems that use VLAN networking by exhausting kernel memory, potentially causing service instability, process termination by the OOM killer, network disruption, or a system crash/reboot. Because exploitation requires local privileges and VLAN configuration capability, the risk is highest on multi-user Linux systems, container hosts, virtualization platforms, network appliances, and servers where less-trusted administrators or workloads can influence network device configuration. EPSS is currently very low and there is no known KEV listing or ransomware association, so broad internet-scale exploitation is unlikely, but the operational impact on affected hosts can still be high if a local attacker or compromised privileged workload abuses it.

How an attack unfolds

An attacker first obtains local access to a Linux host and gains the ability to change VLAN interface configuration, typically through elevated privileges or delegated network administration capabilities such as CAP_NET_ADMIN. The attacker then creates or targets an 802.1Q VLAN device and repeatedly sets and clears egress QoS priority mappings, varying skb priorities so that each cycle creates additional mapping nodes. On vulnerable kernels, clearing a mapping does not remove the underlying node from the hash structure, so memory consumption grows over time. By sustaining the loop, the attacker can force kernel memory pressure, trigger OOM events, disrupt applications and networking, or crash the host. Removing the VLAN device may release the accumulated mappings, but the proper fix is a kernel update containing the patch that deletes cleared egress QoS mappings.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or upstream stable branch that includes the fix for the 8021q change titled "delete cleared egress QoS mappings." No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to identify the corrected release for each distribution. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN and other network-administration privileges, preventing untrusted containers from managing host networking, and limiting who can create or modify VLAN devices. Consider removing unnecessary VLAN interfaces or disabling unused 802.1Q VLAN functionality on systems where it is not required. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a build that includes the 8021q egress QoS mapping deletion fix. Validate with distribution security advisories, kernel changelogs, or source inspection for the patch that removes cleared egress mappings instead of retaining tombstones. On Linux hosts, compare `uname -r` against the vendor-fixed kernel version and confirm the booted kernel matches the patched package. Review whether VLAN devices are in use and whether any users, services, or containers have CAP_NET_ADMIN. If testing in a controlled lab, repeated egress QoS mapping set/clear operations should no longer cause unbounded kernel memory growth on a fixed kernel.

Typical attack path

1. Gain local access to an affected Linux system.
2. Obtain privileges or capabilities that permit network/VLAN configuration, such as root or CAP_NET_ADMIN.
3. Create or identify an 802.1Q VLAN interface.
4. Repeatedly set egress QoS mappings using distinct skb priority values.
5. Clear those mappings so the vulnerable kernel retains tombstone mapping nodes.
6. Continue the set/clear cycle until kernel memory pressure causes service degradation, OOM kills, networking instability, or system failure.

How to detect it

Look for evidence of repeated VLAN egress QoS configuration changes followed by kernel memory pressure. Useful sources include systemd journal, `/var/log/kern.log`, `/var/log/messages`, auditd logs, sudo logs, shell history, process accounting, container runtime logs, and network management service logs. Search for frequent invocations of tools that manipulate VLAN interfaces, such as `ip`, `bridge`, `vconfig`, `tc`, NetworkManager, systemd-networkd, or orchestration components with host network privileges. On systems with auditd configured for netlink or command execution, look for repeated `RTM_SETLINK`-style network configuration changes involving VLAN devices and egress QoS maps. Correlate these events with increasing slab/kernel memory usage, OOM killer messages, service restarts, or unexpected reboots. Because the issue is a memory leak rather than a code-execution bug, there may be no unique exploit artifact; detection is behavioral and based on unusual configuration churn plus memory exhaustion.

• 8021q
• egress-qos-map
• reorder_hdr
• GVRP
• MVRP
• ip link set
• ip link add link
• type vlan
• vconfig add
• vconfig set_egress_map
• RTM_SETLINK
• NETLINK_ROUTE
• Out of memory: Killed process
• oom-killer
• Memory cgroup out of memory
• kernel: Out of memory
• kernel: Killed process
• invoked oom-killer
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching Linux hosts where untrusted users, containers, tenants, or delegated administrators can perform network configuration or hold CAP_NET_ADMIN.
• Inventory systems using 802.1Q VLAN interfaces and identify kernels that predate the vendor fix.
• Restrict CAP_NET_ADMIN, privileged containers, host-network access, and VLAN configuration rights to trusted administrative workflows only.
• Monitor for abnormal VLAN egress QoS configuration activity, repeated netlink network-configuration changes, unexplained kernel memory growth, and OOM killer events.
• Reboot systems after applying patched kernel packages and verify the running kernel version.
• For high-availability systems, schedule rolling kernel updates to avoid unexpected downtime from memory exhaustion.
• If suspicious activity is found, preserve kernel logs, audit logs, command history, container runtime logs, and evidence of network namespace or VLAN configuration changes before rebooting.