// For flags

CVE-2024-26804

net: ip_tunnel: prevent perpetual headroom growth

Severity Score

5.3
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ip_tunnel: evita el crecimiento perpetuo del espacio libre syzkaller activado después de kasan splat: ERROR: KASAN: use-after-free en __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Lectura del tamaño 1 en la dirección ffff88812fb4000e mediante la tarea 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_key incluir/linux /skbuff.h:1514 [en línea] ___skb_get_hash net/core/flow_dissector.c:1791 [en línea] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [en línea] 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 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] 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 [en línea] 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 incluir /linux /netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 . .. El símbolo se produce porque skb->data apunta más allá del área asignada de skb->head. Esto se debe a que la capa vecina hace: __skb_pull(skb, skb_network_offset(skb)); ... pero skb_network_offset() devuelve un desplazamiento negativo y el argumento __skb_pull() no está firmado. OIA, nosotros, skb->los datos, se "ajustan" en un valor enorme. El valor negativo se devuelve porque la distancia de skb->head y skb->data es superior a 64k y skb->network_header (u16) se ha ajustado. El error está en la infraestructura ip_tunnel, lo que puede hacer que dev->needed_headroom se incremente hasta el infinito. El reproductor syzkaller consta de paquetes que se enrutan a través de un túnel gre y una ruta de paquetes encapsulados gre que apuntan a otro túnel (ipip). La encapsulación ipip encuentra gre0 como el siguiente dispositivo de salida. Esto da como resultado el siguiente patrón: 1). El primer paquete se enviará a través de gre0. La búsqueda de ruta encontró un dispositivo de salida, ipip0. 2). ip_tunnel_xmit para gre0 aumenta gre0->needed_headroom según el dispositivo de salida futuro, rt.dev->needed_headroom (ipip0). 3). ipoutput/start_xmit mueve skb a ipip0. que ejecuta la misma ruta de código nuevamente (xmit recursividad). 4). El paso de enrutamiento para el paquete post-gre0-encap encuentra gre0 como dispositivo de salida para usar con el paquete encapsulado ipip0. tunl0->needed_headroom luego se incrementa según el espacio libre del dispositivo gre0 (ya aumentado). Esto se repite para cada paquete futuro: gre0->needed_headroom se infla porque el paso ipip0 de los paquetes anteriores incrementó el espacio libre rt->dev (gre0), y ipip0 se incrementó porque se aumentó el espacio necesario_headroom de gre0. Para cada paquete posterior, gre/ipip0->needed_headroom crece hasta que las reasignaciones posteriores a la expansión del cabezal dan como resultado una distancia skb->head/data de más de 64k. Una vez que eso sucede, skb->network_header (u16) se ajusta cuando pskb_expand_head intenta asegurarse de que skb_network_offset() no cambie después de la expansión/reasignación del espacio libre. Después de esto, skb_network_offset(skb) devuelve un resultado diferente (y negativo) posterior a la expansión del espacio libre.---trucado---

A use-after-free flaw was found in the Linux kernel’s ip_tunnel functionality when a user uses the ip_tunnel infrastructure. This flaw allows a local user to crash the system.

*Credits: N/A
CVSS Scores
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-02-19 CVE Reserved
  • 2024-04-04 CVE Published
  • 2024-04-05 EPSS Updated
  • 2024-12-19 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-416: Use After Free
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.34 < 5.4.271
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.34 < 5.4.271"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.34 < 5.10.212
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.34 < 5.10.212"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.34 < 5.15.151
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.34 < 5.15.151"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.34 < 6.1.81
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.34 < 6.1.81"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.34 < 6.6.21
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.34 < 6.6.21"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.34 < 6.7.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.34 < 6.7.9"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.34 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.34 < 6.8"
en
Affected