CVE-2026-80615 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone
kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the structure to the options_len, which is then initialized to zero. Later, we're initializing the structure by copying the tunnel info together with the options, and this triggers a warning for a potential memcpy overflow, since the compiler estimates that the options can't fit into the structure, even though the memory for them is actually allocated.
memcpy: detected buffer overflow: 104 byte write of buffer size 96 WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report skb_tunnel_info_unclone+0x179/0x190 geneve_xmit+0x7fe/0xe00
The issue is triggered when built with clang and source fortification.
Fix that by doing the copy in two stages: first - the main data with the options_len, then the options. This way the correct length should be known at the time of the copy.
It would be better if the options_len never changed after allocation, but the allocation code is a little separate from the initialization and it would be awkward and potentially dangerous to return a struct with options_len set to a non-zero value from the metadata_dst_alloc().
Another option would be to use ip_tunnel_info_opts_set(), but it is doing too many unnecessary operations for the use case here.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel vulnerability identified in net: dst_metadata involves a false-positive buffer overflow warning triggered during the initialization of tunnel destination metadata structures, specifically within the tun_dst_unclone function when compiled with Clang and source fortification enabled. The root cause lies in how memory allocation and subsequent data copying interact with compiler-enforced bounds checking mechanisms. During the execution of metadata_dst_alloc, the kmalloc_flex macro is utilized to allocate a flexible array member structure where the size of the options buffer is determined by the variable options_len. This variable is initially set to zero at the time of allocation to satisfy structural constraints and avoid returning an improperly initialized object from the allocator function. However, this initialization strategy creates a discrepancy between the actual allocated memory footprint and what static analysis tools perceive as available space.
When the system proceeds to initialize the structure by copying tunnel information along with associated options using memcpy, the compiler's fortification layer detects a potential buffer overflow. This occurs because __fortify_report evaluates the copy operation against the initial value of options_len, which is zero or insufficiently reflective of the dynamically allocated tail memory. Consequently, even though the kernel has correctly reserved space for these additional bytes via kmalloc_flex, the static analysis perceives a write exceeding the declared buffer size, leading to a warning about a 104-byte write against an apparent 96-byte buffer limit. This false positive disrupts development workflows and can obscure genuine security issues if not properly addressed through code restructuring rather than disabling protections.
The operational impact of this vulnerability is primarily related to build-time failures or runtime warnings that may halt execution in strict environments, although it does not represent a true exploitable memory corruption due to the correct underlying allocation logic. The issue highlights the challenges of integrating flexible array members with modern compiler hardening features like source fortification, which rely on compile-time knowledge of buffer sizes for safety checks. To resolve this without compromising security or performance, the fix implements a two-stage copy mechanism. First, the main data portion is copied using the known initial length parameters, and subsequently, the options are appended in a separate operation where the correct total size context is established. This approach ensures that the compiler's bounds checking aligns with actual memory usage patterns while maintaining separation between allocation logic and initialization details.
From a standards perspective, this vulnerability relates to CWE-134: Use of Externally-Controlled Format String or more accurately in this context CWE-672: Use of Operation on Uninitialized Variable if viewed through the lens of uninitialized state leading to incorrect bounds calculation, though it is technically a false positive stemming from static analysis limitations regarding flexible arrays. In terms of ATT&CK mapping, while not an active exploit vector, such issues fall under T1059: Command and Scripting Interpreter or broader software development lifecycle vulnerabilities where toolchain misconfigurations can lead to security blind spots. Mitigation strategies involve adopting the two-stage copy pattern demonstrated in this patch, ensuring that any dynamic size changes are reflected before memory operations occur. Additionally developers should consider using specialized helper functions like ip_tunnel_info_opts_set if they provide cleaner integration with fortification checks, although performance overhead must be weighed against clarity and safety benefits. Maintaining strict alignment between allocation sizes and subsequent access patterns remains critical for preventing both real overflows and false positives in hardened kernel builds.