CVE-2024-26804 in Linux
Summary
by MITRE • 04/04/2024
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/04/2025
The vulnerability described in CVE-2024-26804 affects the Linux kernel's networking stack, specifically within the ip_tunnel subsystem. This issue manifests as a use-after-free condition that stems from improper handling of packet headroom calculations during tunnel encapsulation operations. The flaw is triggered when packets are routed through nested tunneling configurations involving GRE and IPIP tunnels, leading to unbounded growth in required headroom space. The root cause lies in how the kernel calculates and updates device headroom requirements during packet transmission, creating a recursive loop that continuously inflates these values without proper bounds checking.
The technical execution of this vulnerability begins with a specific sequence involving routing and tunneling operations. When a packet traverses through a GRE tunnel and subsequently gets encapsulated by an IPIP tunnel, the kernel's routing logic causes the system to recursively process the same tunneling path multiple times. During each iteration, the ip_tunnel_xmit function increments the required headroom for the output device based on the future device's headroom requirements. This creates a feedback loop where each packet processing step increases the headroom requirement, eventually leading to memory layout issues. The kernel's skb (socket buffer) structure maintains a headroom area for packet manipulation, but when headroom requirements grow excessively, the distance between skb->head and skb->data pointers exceeds 64 kilobytes, causing a wraparound in the 16-bit network_header field.
The operational impact of this vulnerability is severe as it leads to memory corruption and potential system instability. The use-after-free condition occurs when the kernel attempts to access memory that has already been freed or improperly managed due to the skewed headroom calculations. The KASAN (Kernel Address Sanitizer) report shows that the kernel attempts to read from an address that lies outside the valid memory range allocated for the socket buffer, specifically at address ffff88812fb4000e. This memory access violation can result in system crashes, data corruption, or potentially exploitable conditions that could allow privilege escalation. The vulnerability is particularly dangerous in network-intensive environments where tunneling operations are frequent, as it can cause progressive memory exhaustion and system degradation.
The mitigation strategy implemented in the fix involves capping the headroom increment to an arbitrary upper limit, preventing the perpetual growth of needed_headroom values. This approach addresses the core issue by introducing a reasonable bound on how much headroom can be requested, effectively breaking the recursive inflation cycle. The solution aligns with common security practices for preventing resource exhaustion attacks and follows established patterns for handling unbounded growth in kernel data structures. This fix prevents the system from entering the state where the skb->network_header field wraps around, thus avoiding the subsequent memory access violations. The approach is consistent with the principle of bounded resource management and demonstrates proper defensive programming practices that should be applied to similar kernel subsystems handling dynamic memory requirements. The vulnerability highlights the importance of bounds checking in kernel networking code and the potential for seemingly benign operations to create cascading effects that compromise system stability and security.