CVE-2026-80615

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone<br /> <br /> kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the<br /> structure to the options_len, which is then initialized to zero.<br /> Later, we&amp;#39;re initializing the structure by copying the tunnel info<br /> together with the options, and this triggers a warning for a potential<br /> memcpy overflow, since the compiler estimates that the options can&amp;#39;t<br /> fit into the structure, even though the memory for them is actually<br /> allocated.<br /> <br /> memcpy: detected buffer overflow: 104 byte write of buffer size 96<br /> WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report<br /> skb_tunnel_info_unclone+0x179/0x190<br /> geneve_xmit+0x7fe/0xe00<br /> <br /> The issue is triggered when built with clang and source fortification.<br /> <br /> Fix that by doing the copy in two stages: first - the main data with<br /> the options_len, then the options. This way the correct length should<br /> be known at the time of the copy.<br /> <br /> It would be better if the options_len never changed after allocation,<br /> but the allocation code is a little separate from the initialization<br /> and it would be awkward and potentially dangerous to return a struct<br /> with options_len set to a non-zero value from the metadata_dst_alloc().<br /> <br /> Another option would be to use ip_tunnel_info_opts_set(), but it is<br /> doing too many unnecessary operations for the use case here.