CVE-2024-26804

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