CVE-2024-26804: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-26804

In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.

AI Analysis

Technical Summary

CVE-2024-26804 is a medium-severity vulnerability in the Linux kernel's IP tunnel infrastructure, specifically affecting the handling of GRE (Generic Routing Encapsulation) and IP-in-IP tunnels. The root cause is a use-after-free condition triggered by improper management of socket buffer (skb) headroom during packet transmission through nested tunnels. The vulnerability arises because the kernel's ip_tunnel_xmit function increments the needed_headroom field of network devices recursively when packets are routed through GRE tunnels encapsulated within IP-in-IP tunnels, leading to perpetual growth of headroom requirements. This causes skb->head and skb->data pointers to become misaligned, with skb->network_header (a 16-bit unsigned integer) wrapping around due to the headroom exceeding 64KB. Consequently, skb_network_offset() returns a negative offset, which is interpreted as a large unsigned value in __skb_pull(), causing skb->data to point outside the allocated skb->head buffer. This use-after-free condition can lead to memory corruption and potential kernel crashes (denial of service). The vulnerability was discovered via syzkaller fuzzing and is triggered by a specific packet routing pattern involving GRE and IP-in-IP tunnels referencing each other as output devices, causing recursive headroom inflation. The fix involves capping the needed_headroom increments to prevent unbounded growth. The CVSS 3.1 score is 5.3 (medium), reflecting a network attack vector with no privileges or user interaction required, causing availability impact but no confidentiality or integrity loss. No known exploits are reported in the wild yet.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to infrastructure relying on Linux-based systems that use GRE or IP-in-IP tunneling, common in VPNs, cloud environments, and complex network topologies. Exploitation could lead to kernel crashes causing denial of service on critical network devices such as routers, firewalls, or servers, disrupting business operations and network availability. Given the prevalence of Linux in European data centers, telecom infrastructure, and enterprise environments, the impact could be significant especially for providers offering tunneling services or multi-tenant cloud platforms. Although the vulnerability does not directly compromise confidentiality or integrity, denial of service in core network components could indirectly affect service availability and reliability, potentially impacting sectors like finance, healthcare, and government services that depend on continuous network uptime. The lack of required privileges or user interaction lowers the barrier for remote exploitation, increasing the threat surface for exposed systems.

Mitigation Recommendations

European organizations should prioritize patching Linux kernels to versions that include the fix capping needed_headroom increments in the ip_tunnel subsystem. Network administrators should audit their use of GRE and IP-in-IP tunnels, especially nested or recursive tunnel configurations, and consider temporary mitigation by disabling or restricting such tunnels if patching is delayed. Monitoring kernel logs for anomalies related to skb buffer handling or unexpected headroom growth can provide early detection. Employing network segmentation to isolate tunnel endpoints and limiting exposure of tunnel interfaces to untrusted networks reduces attack surface. Additionally, organizations should implement robust kernel hardening and memory protection mechanisms (e.g., Kernel Address Sanitizer, KASAN) in testing environments to detect similar issues proactively. Coordination with Linux distribution vendors for timely updates and validation of kernel patches is critical. Finally, integrating vulnerability scanning tools that detect vulnerable kernel versions can help maintain situational awareness.