// For flags

CVE-2021-47607

bpf: Fix kernel address leakage in atomic cmpxchg's r0 aux reg

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:

bpf: Fix kernel address leakage in atomic cmpxchg's r0 aux reg

The implementation of BPF_CMPXCHG on a high level has the following parameters:

.-[old-val] .-[new-val]
BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG)
`-[mem-loc] `-[old-val]

Given a BPF insn can only have two registers (dst, src), the R0 is fixed and
used as an auxilliary register for input (old value) as well as output (returning
old value from memory location). While the verifier performs a number of safety
checks, it misses to reject unprivileged programs where R0 contains a pointer as
old value.

Through brute-forcing it takes about ~16sec on my machine to leak a kernel pointer
with BPF_CMPXCHG. The PoC is basically probing for kernel addresses by storing the
guessed address into the map slot as a scalar, and using the map value pointer as
R0 while SRC_REG has a canary value to detect a matching address.

Fix it by checking R0 for pointers, and reject if that's the case for unprivileged
programs.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la fuga de dirección del kernel en el registro auxiliar r0 de atomic cmpxchg. La implementación de BPF_CMPXCHG en un nivel alto tiene los siguientes parámetros: .-[old-val] .-[new-val ] BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG) `-[mem-loc] `-[old-val] Dado un BPF insn solo puede tener dos registros (dst, src), el R0 es fijo y se utiliza como registro auxiliar para la entrada (valor anterior), así como para la salida (devolver el valor anterior desde la ubicación de la memoria). Si bien el verificador realiza una serie de comprobaciones de seguridad, no rechaza los programas sin privilegios donde R0 contiene un puntero como valor antiguo. A través de la fuerza bruta, en mi máquina se necesitan aproximadamente 16 segundos para filtrar un puntero del kernel con BPF_CMPXCHG. Básicamente, PoC busca direcciones del kernel almacenando la dirección adivinada en la ranura del mapa como un escalar y usando el puntero del valor del mapa como R0, mientras que SRC_REG tiene un valor canario para detectar una dirección coincidente. Solucionelo comprobando R0 en busca de punteros y rechácelo si ese es el caso de los programas sin privilegios.

*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-05-24 CVE Reserved
  • 2024-06-19 CVE Published
  • 2024-06-20 EPSS Updated
  • 2024-09-11 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.12 < 5.15.11
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.12 < 5.15.11"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.12 < 5.16
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.12 < 5.16"
en
Affected