CVE-2026-43067

In the Linux kernel, the following vulnerability has been resolved: ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups().
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.1.167:*:*:*:*:*:*:*

History

11 Nov 2026, 23:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ext4: manejar el desbordamiento al buscar bloques para bloques mapeados indirectamente El commit 4865c768b563 (’ext4: siempre asignar bloques solo de grupos que el inodo puede usar’) restringe qué bloques se asignarán para archivos basados en bloques indirectos a números de bloque que encajen dentro de números de bloque de 32 bits. Sin embargo, al usar un bot de revisión ejecutándose en el último LLM Gemini para verificar este commit al hacer un backport a un kernel basado en LTS, planteó esta preocupación: ’Si ac -> ac_g_ex.fe_group es mayor o igual que ngroups (por ejemplo, si el grupo objetivo fue poblado mediante asignación de flujo desde s_mb_last_groups), entonces start será mayor o igual que ngroups. ¿Permite esto asignar bloques más allá del límite de 32 bits para archivos mapeados por bloques indirectos? El mensaje del commit menciona que ext4_mb_scan_groups_linear() se encarga de no seleccionar grupos no soportados. Sin embargo, su bucle usa group = start, y la primera iteración llamará a ext4_mb_scan_group() con este grupo no soportado porque next_linear_group() solo se llama al final de la iteración.’ Después de revisar las rutas de código involucradas y considerar la revisión del LLM, determiné que esto puede ocurrir cuando hay un sistema de archivos donde algunos archivos/directorios están mapeados por extensiones y otros están mapeados por bloques indirectos. Para abordar esto, añadir un límite de seguridad en ext4_mb_scan_groups().

19 Oct 2026, 20:18

Type Values Removed Values Added
CWE CWE-822

Information

Published : 2026-05-05 16:16

Updated : 2026-11-11 23:10


NVD link : CVE-2026-43067

Mitre link : CVE-2026-43067

CVE.ORG link : CVE-2026-43067


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
NVD-CWE-noinfo CWE-822

Untrusted Pointer Dereference