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