CVE-2025-21920: Linux Kernel Information Disclosure Flaw

CVE-2025-21920 Overview

CVE-2025-21920 is an out-of-bounds read vulnerability [CWE-125] in the Linux kernel's VLAN (Virtual Local Area Network) subsystem. The flaw allows local users to leak kernel function addresses to user space, defeating Kernel Address Space Layout Randomization (KASLR). The vulnerability occurs when a VLAN device is created on top of a non-ethernet underlying device, such as an IPv6 GRE tunnel. During initialization, the Generic Attribute Registration Protocol (GARP) and Multiple Registration Protocol (MRP) applicants call dev_mc_add, which reads dev->addr_len bytes from a fixed 6-byte multicast address buffer.

Critical Impact
Local unprivileged users can leak kernel function addresses, undermining KASLR and enabling further kernel exploitation.

Affected Products

Linux Kernel (multiple stable branches prior to the fix)
Linux Kernel 6.14-rc1 through 6.14-rc5
Debian LTS distributions (see Debian LTS Announcements #30 and #45)

Discovery Timeline

2025-04-01 - CVE-2025-21920 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-21920

Vulnerability Analysis

The vulnerability resides in the Linux kernel VLAN subsystem, specifically in how it initializes GARP and MRP applicants for an underlying network device. When a user creates a VLAN device using ip link add, the kernel calls garp_init_applicant and mrp_init_applicant for the underlying device. Both functions register 6-byte multicast addresses through dev_mc_add.

The internal __dev_mc_add function reads dev->addr_len bytes from the multicast address buffer. Ethernet devices use a 6-byte hardware address, matching the multicast address size. Non-ethernet devices such as ip6gre tunnels report a larger addr_len, causing the kernel to read beyond the 6-byte buffer.

The leaked bytes originate from adjacent kernel .rodata or function pointers. Attackers observe the leaked address by inspecting multicast group membership through ip maddr show.

Root Cause

The VLAN subsystem does not validate the type of the underlying device before initializing GARP and MRP applicants. Constants like the GARP multicast address (01:80:c2:00:00:21) are hardcoded at 6 bytes and assume an ethernet underlying device. The mismatch between the fixed source buffer size and the dynamically sized destination read length produces the out-of-bounds read [CWE-125].

Attack Vector

A local user with permission to create network interfaces can trigger the bug with three commands: creating an ip6gre tunnel, bringing it up, and attaching a VLAN device to it. Reading /proc/net/dev_mcast or running ip maddr show then reveals the leaked kernel pointer bytes appended to the expected multicast address. The leaked address of garp_pdu_rcv provides a reliable anchor for computing the kernel base and bypassing KASLR.

No verified public proof-of-concept code is available. See the upstream commits referenced under Patch Information for the corrected initialization logic.

Detection Methods for CVE-2025-21920

Indicators of Compromise

Creation of VLAN devices layered on non-ethernet interfaces such as ip6gre, ipip, or sit tunnels
Unexpected multicast group entries longer than 6 bytes appearing in /proc/net/dev_mcast
Unprivileged processes invoking ip link add ... type vlan shortly after creating tunnel devices

Detection Strategies

Audit kernel logs and netlink events for RTM_NEWLINK messages that combine tunnel creation with VLAN attachment
Monitor ip maddr show output for multicast addresses containing trailing non-standard bytes indicative of the leak
Correlate process telemetry to identify non-root users invoking iproute2 commands that create both tunnel and VLAN devices

Monitoring Recommendations

Enable Linux auditd rules for execve calls to ip with link add and tunnel add arguments
Track kernel version inventory across Linux fleets to prioritize hosts running unpatched 6.14-rc and earlier stable kernels
Alert on any process reading /proc/net/dev_mcast from a non-administrative user context

How to Mitigate CVE-2025-21920

Immediate Actions Required

Apply the latest stable Linux kernel update from your distribution vendor
Restrict CAP_NET_ADMIN to trusted administrators and audit user namespace configurations that grant it to unprivileged users
Disable user namespaces on multi-tenant hosts where unprivileged network device creation is not required

Patch Information

The upstream fix enforces that the underlying device is an ethernet device before initializing VLAN GARP and MRP applicants. Backport commits are available across stable branches including 0fb7aa04c19e, 30e8aee77899, 3561442599804, 5a515d13e155, 7f1564b2b207, b33a53461006, b6c72479748b, and fa40ebef6923. Debian LTS shipped fixes in Debian LTS Announcements DLA #30 and DLA #45.

Workarounds

Do not create VLAN devices on top of non-ethernet interfaces such as GRE, IP-in-IP, or SIT tunnels
Block loading of the 8021q kernel module on systems that do not require VLAN functionality using /etc/modprobe.d blacklists
Remove CAP_NET_ADMIN from unprivileged workloads and containers to prevent creation of arbitrary link types

bash

# Blacklist the 8021q VLAN module on hosts that do not require VLANs
echo 'install 8021q /bin/true' | sudo tee /etc/modprobe.d/disable-8021q.conf
sudo rmmod 8021q 2>/dev/null || true

# Verify current kernel version against patched stable releases
uname -r