CVE-2025-22075 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ---truncated---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability identified as CVE-2025-22075 resides within the Linux kernel's rtnetlink subsystem, specifically affecting how netlink messages are allocated when retrieving virtual function (VF) port and node global unique identifiers (GUIDs). This flaw manifests in scenarios where a large number of VFs are configured on a network interface, such as an InfiniBand device named ib0, leading to a "Message too long" error during operations like ip link show dev ib0. The root cause stems from an incorrect calculation of the buffer size required for netlink message construction when VF GUIDs are included in the output, resulting in memory allocation that is insufficient to accommodate the data being transmitted.
The technical implementation of this vulnerability is tied to the function rtnl_getlink in the net/core/rtnetlink.c file, where the kernel attempts to construct a netlink message containing VF information. The commit 30aad41721e0 introduced support for VF GUIDs but failed to account for their size during allocation, causing a buffer overflow condition. The kernel warning message indicates that the function has encountered a memory boundary violation, with the error occurring at line 4151 of rtnetlink.c, suggesting a direct consequence of insufficiently sized buffers when multiple GUIDs are present. This misalignment between allocated and required memory space leads to the kernel's warning mechanism being triggered and ultimately causes the netlink message to be rejected due to size constraints.
From an operational standpoint, this vulnerability can severely impact network management and monitoring capabilities in environments that rely on SR-IOV (Single Root I/O Virtualization) for high-performance networking, particularly in data center and cloud computing infrastructures. When administrators attempt to query network interface details for devices with many configured VFs, the command execution fails, disrupting automation scripts, monitoring tools, and network diagnostic procedures. The issue becomes more pronounced with higher VF counts, such as the 64 VFs demonstrated in the error scenario, where the cumulative size of GUID data exceeds the pre-allocated buffer space, leading to communication failures between user-space applications and the kernel's netlink interface. This can result in operational downtime or misconfigurations, especially in high-density networking environments where detailed VF information is routinely required.
Mitigation strategies for this vulnerability involve patching the Linux kernel to properly account for VF GUID sizes during netlink message allocation, ensuring that the buffer size calculation includes the space required for GUID data fields. The fix should be implemented by modifying the rtnl_getlink function to dynamically compute the required message size based on the number of VFs and their associated GUID information. Organizations should prioritize applying the official kernel patches from their distribution vendors or directly from the Linux kernel source tree, particularly for systems running kernel versions that include the problematic commit. Additionally, administrators should consider temporarily reducing the number of VFs configured on affected interfaces as a workaround until the patch is deployed. Monitoring systems should be updated to detect and alert on netlink message size errors, and network management tools should be tested for compatibility with the corrected kernel behavior to prevent operational disruptions during patch deployment.
This vulnerability aligns with CWE-129, which describes improper validation of buffer sizes, and relates to ATT&CK technique T1059.003, where adversaries might exploit such kernel-level flaws to manipulate network communication channels. The flaw demonstrates a classic case of insufficient input validation in kernel space, where the system fails to properly account for variable-length data structures during memory allocation. The vulnerability also intersects with network reconnaissance and system enumeration activities, as it can be leveraged to identify the presence of SR-IOV capable hardware and the configuration of virtual functions, potentially exposing network infrastructure details to unauthorized parties. Proper patch management and kernel hardening practices are essential to prevent exploitation of this class of vulnerabilities that could lead to broader system compromise or denial-of-service conditions in networked environments.