CVE-2024-26804
net: ip_tunnel: prevent perpetual headroom growth
Severity Score
Exploit Likelihood
Affected Versions
Public Exploits
0Exploited in Wild
-Decision
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.
CVSS Scores
SSVC
- Decision:Track
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
References (11)
URL | Tag | Source |
---|---|---|
https://git.kernel.org/stable/c/243aad830e8a4cdda261626fbaeddde16b08d04a | Vuln. Introduced | |
https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html |
URL | Date | SRC |
---|
URL | Date | SRC |
---|---|---|
https://access.redhat.com/security/cve/CVE-2024-26804 | 2024-07-23 | |
https://bugzilla.redhat.com/show_bug.cgi?id=2273423 | 2024-07-23 |
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
|