// For flags

CVE-2024-35798

btrfs: fix race in read_extent_buffer_pages()

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:

btrfs: fix race in read_extent_buffer_pages()

There are reports from tree-checker that detects corrupted nodes,
without any obvious pattern so possibly an overwrite in memory.
After some debugging it turns out there's a race when reading an extent
buffer the uptodate status can be missed.

To prevent concurrent reads for the same extent buffer,
read_extent_buffer_pages() performs these checks:

/* (1) */
if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))
return 0;

/* (2) */
if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags))
goto done;

At this point, it seems safe to start the actual read operation. Once
that completes, end_bbio_meta_read() does

/* (3) */
set_extent_buffer_uptodate(eb);

/* (4) */
clear_bit(EXTENT_BUFFER_READING, &eb->bflags);

Normally, this is enough to ensure only one read happens, and all other
callers wait for it to finish before returning. Unfortunately, there is
a racey interleaving:

Thread A | Thread B | Thread C
---------+----------+---------
(1) | |
| (1) |
(2) | |
(3) | |
(4) | |
| (2) |
| | (1)

When this happens, thread B kicks of an unnecessary read. Worse, thread
C will see UPTODATE set and return immediately, while the read from
thread B is still in progress. This race could result in tree-checker
errors like this as the extent buffer is concurrently modified:

BTRFS critical (device dm-0): corrupted node, root=256
block=8550954455682405139 owner mismatch, have 11858205567642294356
expect [256, 18446744073709551360]

Fix it by testing UPTODATE again after setting the READING bit, and if
it's been set, skip the unnecessary read.

[ minor update of changelog ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la ejecución en read_extent_buffer_pages() Hay informes de tree-checker que detecta nodos corruptos, sin ningún patrón obvio por lo que posiblemente se sobrescriba en la memoria. Después de un poco de depuración, resulta que hay una ejecución cuando al leer un búfer de extensión se puede perder el estado de actualización. Para evitar lecturas simultáneas para el mismo búfer de extensión, read_extent_buffer_pages() realiza estas comprobaciones: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) ir a listo; En este punto, parece seguro iniciar la operación de lectura real. Una vez que se completa, end_bbio_meta_read() hace /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normalmente, esto es suficiente para garantizar que solo se realice una lectura y que todos los demás llamantes esperen a que finalice antes de regresar. Desafortunadamente, hay un entrelazado racial: Hilo A | Hilo B | Rosca C ---------+----------+----------------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) Cuando esto sucede, el hilo B inicia una lectura innecesaria. Peor aún, el subproceso C verá la ACTUALIZACIÓN configurada y regresará inmediatamente, mientras la lectura del subproceso B aún está en progreso. Esta ejecución podría dar como resultado errores del comprobador de árbol como este, ya que el búfer de extensión se modifica simultáneamente: BTRFS crítico (dispositivo dm-0): nodo dañado, raíz=256 bloque=8550954455682405139 el propietario no coincide, tiene 11858205567642294356 expect [256, 18446744073709551360] Arreglarlo probando UPTODATE nuevamente después de configurar el bit de LECTURA y, si se ha configurado, omita la lectura innecesaria. [actualización menor del registro de cambios]

*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-17 CVE Reserved
  • 2024-05-17 CVE Published
  • 2024-05-18 EPSS Updated
  • 2024-08-02 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"
>= 6.5 < 6.6.24
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.5 < 6.6.24"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.5 < 6.7.12
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.5 < 6.7.12"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.5 < 6.8.3
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.5 < 6.8.3"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.5 < 6.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.5 < 6.9"
en
Affected