CVE-2025-21920 is a vulnerability in the Linux kernel related to VLAN (Virtual LAN) device creation on non-ethernet underlying devices. Normally, VLAN devices are expected to be created on ethernet devices, but this vulnerability arises because the Linux kernel allows VLAN devices to be created on top of non-ethernet devices, which is logically inconsistent and leads to a security flaw. Specifically, during VLAN device initialization, the kernel initializes GARP (Generic Attribute Registration Protocol) and MRP (Multiple Registration Protocol) applicants for the underlying device. These protocols add multicast addresses to the underlying device via the dev_mc_add function. The function __dev_mc_add uses the underlying device's address length (dev->addr_len) to determine the length of the multicast address to add. However, if dev->addr_len is greater than 6 (the length of standard ethernet MAC addresses), an out-of-bounds read occurs because the multicast addresses from GARP and MRP are only 6 bytes long. This out-of-bounds read leads to leaking the address of a kernel function (garp_pdu_rcv) to user mode, which can aid attackers in bypassing kernel address space layout randomization (KASLR) and facilitate further exploitation. The vulnerability can be reproduced by creating a GRE tunnel device with IPv6 GRE mode, setting it up, and then creating a VLAN device on top of it, followed by querying multicast addresses to leak kernel function pointers. The root cause is the lack of enforcement of the underlying device type during VLAN device initialization. The fix involves enforcing that VLAN devices can only be created on ethernet devices, preventing the out-of-bounds read and kernel address leakage. This vulnerability affects Linux kernel versions identified by the commit hash 22bedad3ce112d5ca1eaf043d4990fa2ed698c87 and presumably versions before the patch was applied. No known exploits are currently in the wild, and no CVSS score has been assigned yet.

For European organizations, this vulnerability poses a risk primarily in environments running Linux kernels vulnerable to this issue, especially in network infrastructure components such as routers, firewalls, and servers that utilize VLANs and GRE tunnels. The leakage of kernel function addresses undermines kernel address space layout randomization (KASLR), a critical security mitigation, potentially enabling attackers to escalate privileges or execute arbitrary code in the kernel context. This can lead to unauthorized access, data breaches, or disruption of network services. Organizations relying on Linux-based network appliances or cloud infrastructure are particularly at risk. The impact is heightened in multi-tenant environments or where untrusted users have the ability to create network interfaces, as they could exploit this flaw to gain sensitive kernel information. Although no active exploits are known, the vulnerability's presence in widely deployed Linux kernels means that attackers could develop exploits, increasing the threat over time. The vulnerability could also affect embedded Linux devices used in industrial control systems or telecommunications, which are critical in European infrastructure. Overall, the vulnerability threatens confidentiality and integrity of systems and could lead to availability issues if exploited to cause kernel crashes or denial of service.

1. Apply the official Linux kernel patch that enforces the underlying device type during VLAN device initialization to prevent VLAN devices from being created on non-ethernet devices. 2. Audit and update all Linux systems, especially network infrastructure devices, to the latest kernel versions that include this fix. 3. Restrict permissions to create or modify network interfaces to trusted administrators only, minimizing the risk of unprivileged users exploiting this vulnerability. 4. Monitor network device creation logs and multicast address queries for unusual activity that may indicate attempts to exploit this vulnerability. 5. In environments where immediate patching is not feasible, consider disabling VLAN creation on non-ethernet devices or disabling GRE tunnels if not required. 6. Employ kernel hardening techniques such as grsecurity or SELinux policies to limit the impact of kernel information leaks. 7. Conduct penetration testing and vulnerability scanning focused on network device configurations to detect potential exploitation attempts. 8. Educate system administrators about this vulnerability and the importance of controlling network interface creation privileges.