// For flags

CVE-2024-26726

btrfs: don't drop extent_map for free space inode on write error

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: don't drop extent_map for free space inode on write error

While running the CI for an unrelated change I hit the following panic
with generic/648 on btrfs_holes_spacecache.

assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
Call Trace:
<TASK>
extent_write_cache_pages+0x2ac/0x8f0
extent_writepages+0x87/0x110
do_writepages+0xd5/0x1f0
filemap_fdatawrite_wbc+0x63/0x90
__filemap_fdatawrite_range+0x5c/0x80
btrfs_fdatawrite_range+0x1f/0x50
btrfs_write_out_cache+0x507/0x560
btrfs_write_dirty_block_groups+0x32a/0x420
commit_cowonly_roots+0x21b/0x290
btrfs_commit_transaction+0x813/0x1360
btrfs_sync_file+0x51a/0x640
__x64_sys_fdatasync+0x52/0x90
do_syscall_64+0x9c/0x190
entry_SYSCALL_64_after_hwframe+0x6e/0x76

This happens because we fail to write out the free space cache in one
instance, come back around and attempt to write it again. However on
the second pass through we go to call btrfs_get_extent() on the inode to
get the extent mapping. Because this is a new block group, and with the
free space inode we always search the commit root to avoid deadlocking
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
requested range.

This happens because the first time we try to write the space cache out
we hit an error, and on an error we drop the extent mapping. This is
normal for normal files, but the free space cache inode is special. We
always expect the extent map to be correct. Thus the second time
through we end up with a bogus extent map.

Since we're deprecating this feature, the most straightforward way to
fix this is to simply skip dropping the extent map range for this failed
range.

I shortened the test by using error injection to stress the area to make
it easier to reproduce. With this patch in place we no longer panic
with my error injection test.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no elimine extend_map para el inodo de espacio libre en el error de escritura Mientras ejecutaba el CI para un cambio no relacionado, encontré el siguiente pánico con generic/648 en btrfs_holes_spacecache. error de aserción: block_start != EXTENT_MAP_HOLE, en fs/btrfs/extent_io.c:1385 ------------[ cortar aquí ]------------ ERROR del kernel en fs /btrfs/extent_io.c:1385! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: cargado Contaminado: GW 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Seguimiento de llamadas: &lt; TAREA&gt; extensión_write_cache_pages+0x2ac/0x8f0 extensión_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_ca che+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813 /0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Esto sucede porque no logramos escribir el espacio libre en caché en una instancia, volvemos e intentamos escribirlo nuevamente. Sin embargo, en el segundo paso, llamamos a btrfs_get_extent() en el inodo para obtener el mapeo de extensión. Debido a que este es un nuevo grupo de bloques, y con el inodo de espacio libre siempre buscamos la raíz de confirmación para evitar un punto muerto con el árbol, no encontramos nada y devolvemos un EXTENT_MAP_HOLE para el rango solicitado. Esto sucede porque la primera vez que intentamos escribir el caché de espacio, encontramos un error y, en caso de error, descartamos la asignación de extensión. Esto es normal para archivos normales, pero el inodo de caché de espacio libre es especial. Siempre esperamos que el mapa de extensión sea correcto. Por lo tanto, la segunda vez terminamos con un mapa de extensión falso. Dado que estamos desaprobando esta función, la forma más sencilla de solucionarlo es simplemente omitir la eliminación del rango del mapa de extensión para este rango fallido. Acorté la prueba usando inyección de error para enfatizar el área y facilitar su reproducción. Con este parche implementado, ya no entraremos en pánico con mi prueba de inyección de errores.

*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-19 CVE Reserved
  • 2024-04-03 CVE Published
  • 2024-04-04 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.1.79
Search vendor "Linux" for product "Linux Kernel" and version " < 6.1.79"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.6.18
Search vendor "Linux" for product "Linux Kernel" and version " < 6.6.18"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.7.6
Search vendor "Linux" for product "Linux Kernel" and version " < 6.7.6"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.8
Search vendor "Linux" for product "Linux Kernel" and version " < 6.8"
en
Affected