// For flags

CVE-2021-47608

bpf: Fix kernel address leakage in atomic fetch

Severity Score

5.5
*CVSS v3

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 fetch The change in commit 37086bfdc737 ("bpf: Propagate stack bounds to registers
in atomics w/ BPF_FETCH") around check_mem_access() handling is buggy since
this would allow for unprivileged users to leak kernel pointers. For example,
an atomic fetch/and with -1 on a stack destination which holds a spilled
pointer will migrate the spilled register type into a scalar, which can then
be exported out of the program (since scalar != pointer) by dumping it into
a map value. The original implementation of XADD was preventing this situation by using
a double call to check_mem_access() one with BPF_READ and a subsequent one
with BPF_WRITE, in both cases passing -1 as a placeholder value instead of
register as per XADD semantics since it didn't contain a value fetch. The
BPF_READ also included a check in check_stack_read_fixed_off() which rejects
the program if the stack slot is of __is_pointer_value() if dst_regno < 0.
The latter is to distinguish whether we're dealing with a regular stack spill/
fill or some arithmetical operation which is disallowed on non-scalars, see
also 6e7e63cbb023 ("bpf: Forbid XADD on spilled pointers for unprivileged
users") for more context on check_mem_access() and its handling of placeholder
value -1. One minimally intrusive option to fix the leak is for the BPF_FETCH case to
initially check the BPF_READ case via check_mem_access() with -1 as register,
followed by the actual load case with non-negative load_reg to propagate
stack bounds to registers.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la fuga de la dirección del kernel en la recuperación atómica. El cambio en el commit 37086bfdc737 ("bpf: propaga los límites de la pila a los registros en atómicos con BPF_FETCH") alrededor del manejo de check_mem_access() tiene errores ya que esto permitiría a usuarios sin privilegios filtrar punteros del kernel. Por ejemplo, una recuperación atómica/y con -1 en un destino de pila que contiene un puntero derramado migrará el tipo de registro derramado a un escalar, que luego se puede exportar fuera del programa (ya que escalar! = puntero) volcándolo en un valor de mapa. La implementación original de XADD evitaba esta situación mediante el uso de una llamada doble a check_mem_access(), una con BPF_READ y otra posterior con BPF_WRITE, en ambos casos pasando -1 como valor de marcador de posición en lugar de registrarse según la semántica de XADD, ya que no lo hacía contener una recuperación de valor. BPF_READ también incluyó una verificación en check_stack_read_fixed_off() que rechaza el programa si la ranura de la pila es de __is_pointer_value() si dst_regno &lt; 0. Esto último es para distinguir si estamos tratando con un derrame/llenado de pila regular o alguna operación aritmética que no está permitido en valores no escalares, consulte también 6e7e63cbb023 ("bpf: Prohibir XADD en punteros dispersos para usuarios sin privilegios") para obtener más contexto sobre check_mem_access() y su manejo del valor del marcador de posición -1. Una opción mínimamente intrusiva para solucionar la fuga es que el caso BPF_FETCH verifique inicialmente el caso BPF_READ mediante check_mem_access() con -1 como registro, seguido del caso de carga real con load_reg no negativo para propagar los límites de la pila a los registros.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kernel address leakage in atomic fetch The change in commit 37086bfdc737 ("bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH") around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value. The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn't contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno < 0. The latter is to distinguish whether we're dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 ("bpf: Forbid XADD on spilled pointers for unprivileged users") for more context on check_mem_access() and its handling of placeholder value -1. One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1 as register, followed by the actual load case with non-negative load_reg to propagate stack bounds to registers.

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
Attack Vector
Local
Attack Complexity
Low
Authentication
Single
Confidentiality
None
Integrity
None
Availability
Complete
* 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-12-19 CVE Updated
  • 2025-03-18 EPSS 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