UBUNTU-CVE-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.
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
29 explicit affected versions
43 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
6 explicit affected versions
52 explicit affected versions
38 explicit affected versions
59 explicit affected versions
49 explicit affected versions
38 explicit affected versions
10 explicit affected versions
45 explicit affected versions
191 explicit affected versions
7 explicit affected versions
46 explicit affected versions
86 explicit affected versions
13 explicit affected versions
85 explicit affected versions
35 explicit affected versions
5 explicit affected versions
14 explicit affected versions
18 explicit affected versions
7 explicit affected versions
118 explicit affected versions
33 explicit affected versions
88 explicit affected versions
13 explicit affected versions
4 explicit affected versions
121 explicit affected versions
23 explicit affected versions
1 explicit affected versions
21 explicit affected versions
9 explicit affected versions
16 explicit affected versions
10 explicit affected versions
43 explicit affected versions
7 explicit affected versions
12 explicit affected versions
111 explicit affected versions
36 explicit affected versions
12 explicit affected versions
14 explicit affected versions
7 explicit affected versions
76 explicit affected versions
12 explicit affected versions
91 explicit affected versions
99 explicit affected versions
12 explicit affected versions
87 explicit affected versions
120 explicit affected versions
10 explicit affected versions
10 explicit affected versions
37 explicit affected versions
13 explicit affected versions
10 explicit affected versions
25 explicit affected versions
1 explicit affected versions
29 explicit affected versions
26 explicit affected versions
13 explicit affected versions
144 explicit affected versions
4 explicit affected versions
1 explicit affected versions
29 explicit affected versions
80 explicit affected versions
13 explicit affected versions
49 explicit affected versions
1 explicit affected versions
75 explicit affected versions
47 explicit affected versions
91 explicit affected versions
9 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
188 explicit affected versions
11 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
90 explicit affected versions
138 explicit affected versions
2 explicit affected versions
37 explicit affected versions
30 explicit affected versions
132 explicit affected versions
46 explicit affected versions
165 explicit affected versions
154 explicit affected versions
10 explicit affected versions
26 explicit affected versions
25 explicit affected versions
1 explicit affected versions
13 explicit affected versions
139 explicit affected versions
49 explicit affected versions
16 explicit affected versions
49 explicit affected versions
39 explicit affected versions
116 explicit affected versions
3 explicit affected versions
93 explicit affected versions
1 explicit affected versions
2 explicit affected versions
56 explicit affected versions
51 explicit affected versions
92 explicit affected versions
2 explicit affected versions
12 explicit affected versions
35 explicit affected versions
27 explicit affected versions
21 explicit affected versions
1 explicit affected versions
1 explicit affected versions
98 explicit affected versions
8 explicit affected versions
10 explicit affected versions
5 explicit affected versions
8 explicit affected versions
1 explicit affected versions
10 explicit affected versions
13 explicit affected versions
79 explicit affected versions
13 explicit affected versions
43 explicit affected versions
7 explicit affected versions
140 explicit affected versions
94 explicit affected versions
41 explicit affected versions
10 explicit affected versions
12 explicit affected versions
12 explicit affected versions
78 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
35 explicit affected versions
37 explicit affected versions
14 explicit affected versions
38 explicit affected versions
167 explicit affected versions
39 explicit affected versions
9 explicit affected versions
38 explicit affected versions
11 explicit affected versions
46 explicit affected versions
8 explicit affected versions
7 explicit affected versions
20 explicit affected versions
97 explicit affected versions
50 explicit affected versions
121 explicit affected versions
4 explicit affected versions
1 explicit affected versions
1 explicit affected versions
44 explicit affected versions
13 explicit affected versions
43 explicit affected versions
44 explicit affected versions
10 explicit affected versions
8 explicit affected versions
14 explicit affected versions
79 explicit affected versions
4 explicit affected versions
68 explicit affected versions
11 explicit affected versions
1 explicit affected versions
69 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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.
05 / REFERENCES
Further evidence
- https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b
- https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee
- https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
- https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9
- https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96
- https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282
- https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383
- https://ubuntu.com/security/CVE-2024-26804
- https://ubuntu.com/security/notices/USN-6820-1
- https://ubuntu.com/security/notices/USN-6820-2
- https://ubuntu.com/security/notices/USN-6821-1
- https://ubuntu.com/security/notices/USN-6821-2
- https://ubuntu.com/security/notices/USN-6821-3
- https://ubuntu.com/security/notices/USN-6821-4
- https://ubuntu.com/security/notices/USN-6828-1
- https://ubuntu.com/security/notices/USN-6831-1
- https://ubuntu.com/security/notices/USN-6867-1
- https://ubuntu.com/security/notices/USN-6871-1
- https://ubuntu.com/security/notices/USN-6892-1
- https://ubuntu.com/security/notices/USN-6919-1
- https://www.cve.org/CVERecord?id=CVE-2024-26804