// For flags

CVE-2021-47036

udp: skip L4 aggregation for UDP tunnel packets

Severity Score

"-"
*CVSS v-

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:

udp: skip L4 aggregation for UDP tunnel packets

If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
are UDP tunnels available in the system, udp_gro_receive() could end-up
doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
the outer UDP tunnel level for packets effectively carrying and UDP
tunnel header.

That could cause inner protocol corruption. If e.g. the relevant
packets carry a vxlan header, different vxlan ids will be ignored/
aggregated to the same GSO packet. Inner headers will be ignored, too,
so that e.g. TCP over vxlan push packets will be held in the GRO
engine till the next flush, etc.

Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
current packet could land in a UDP tunnel, and let udp_gro_receive()
do GRO via udp_sk(sk)->gro_receive.

The check implemented in this patch is broader than what is strictly
needed, as the existing UDP tunnel could be e.g. configured on top of
a different device: we could end-up skipping GRO at-all for some packets.

Anyhow, that is a very thin corner case and covering it will add quite
a bit of complexity.

v1 -> v2:
- hopefully clarify the commit message

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: omitir la agregación L4 para paquetes de túnel UDP Si NETIF_F_GRO_FRAGLIST o NETIF_F_GRO_UDP_FWD están habilitados y hay túneles UDP disponibles en el sistema, udp_gro_receive() podría terminar realizando la agregación L4 (ya sea SKB_GSO_UDP_L4 o SKB_GSO_FRAGLIST) en el nivel del túnel UDP externo para paquetes que transportan efectivamente un encabezado de túnel UDP. Eso podría causar corrupción del protocolo interno. Si, por ejemplo, los paquetes relevantes llevan un encabezado vxlan, se ignorarán/agregarán diferentes ID de vxlan al mismo paquete GSO. Los encabezados internos también se ignorarán, de modo que, por ejemplo, los paquetes push TCP sobre vxlan se mantendrán en el motor GRO hasta el próximo lavado, etc. Simplemente omita la ruta de código SKB_GSO_UDP_L4 y SKB_GSO_FRAGLIST si el paquete actual podría aterrizar en un túnel UDP, y deje que udp_gro_receive() haga GRO a través de udp_sk(sk)->gro_receive. La verificación implementada en este parche es más amplia de lo estrictamente necesario, ya que el túnel UDP existente podría configurarse, por ejemplo, encima de un dispositivo diferente: podríamos terminar omitiendo GRO para algunos paquetes. De todos modos, se trata de una carcasa de esquina muy delgada y cubrirla agregará bastante complejidad. v1 -> v2: - con suerte aclarar el mensaje de confirmación

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-02-27 CVE Reserved
  • 2024-02-28 CVE Published
  • 2024-02-29 EPSS Updated
  • 2024-08-04 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
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"
>= 5.6 < 5.12.4
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.6 < 5.12.4"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.6 < 5.13
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.6 < 5.13"
en
Affected