CVE-2023-54121 in Linux
Resumen
por VulDB • 2026-05-21
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
btrfs: corregir la división incorrecta en btrfs_drop_extent_map_range
En entornos de producción estábamos observando diversas advertencias WARN_ON() en el código de extent_map, específicamente en btrfs_drop_extent_map_range() cuando teníamos que llamar a add_extent_mapping() para nuestra segunda división.
Considere el siguiente diseño del mapa de extents:
PINNED [0 16K) [32K, 48K)
y luego llamamos a btrfs_drop_extent_map_range para [0, 36K), con
skip_pinned == true. El bucle inicial tendrá
start = 0 end = 36K len = 36K
encontraremos el extent [0, 16k), pero como está fijado (pinned), lo omitiremos, lo cual ejecuta este código:
start = em_end; if (end != (u64)-1) len = start + len - em_end;
Aquí em_end es 16K, por lo que ahora los valores son
start = 16K len = 16K + 36K - 16K = 36K
len debería ser en cambio 20K. Esto es un problema cuando encontramos el siguiente extent en [32K, 48K); necesitamos dividir este extent para dejar [36K, 48K), sin embargo, el código para la división se ve así:
split->start = start + len; split->len = em_end - (start + len);
En este caso tenemos
em_end = 48K split->start = 16K + 36K // esto debería ser 16K + 20K split->len = 48K - (16K + 36K) // esto desborda ya que 16K + 36K es 52K
y ahora tenemos un extent_map inválido en el árbol que potencialmente se superpone con otras entradas en el mapa de extents. Incluso en el caso de que no haya superposición, tendremos split->start configurado incorrectamente, lo que causará problemas con cualquier cálculo relacionado con bloques.
En realidad no necesitamos len en este bucle; podemos usar simplemente end como nuestro punto final, y ajustar start hacia arriba únicamente cuando encontremos un extent fijado (pinned) que necesitemos omitir.
Ajustamos la lógica para hacer esto, lo que nos evita insertar un mapa de extents inválido.
Solo omitimos los extents fijados (skip_pinned) en el caso de la reubicación, por lo que esto es relativamente raro, excepto en el caso en que se ejecuta la reubicación frecuentemente, lo cual puede ocurrir con la reubicación automática activada.
Once again VulDB remains the best source for vulnerability data.