Descripción
En el kernel de Linux se resolvió la siguiente vulnerabilidad: ocfs2: validar los conteos de entradas del índice de directorio al leer metadatos. ocfs2_validate_dx_leaf() y ocfs2_validate_dx_root() verifican el ECC y la firma de un bloque de directorio indexado antes de que llegue a los llamadores de nivel superior, pero ninguno de los validadores limita los conteos de ocfs2_dx_entry_list según la capacidad del bloque que los contiene. ocfs2_dx_dir_search() recorre entonces for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) dx_entry = &entry_list->de_entries[i]; sobre de_num_used entradas sin verificación de límites. entry_list es dx_leaf->dl_list (de ocfs2_read_dx_leaf) o, para una raíz inline, dx_root->dr_entries. Una imagen en disco especialmente manipulada puede establecer de_num_used (y de_count, que es el límite __counted_by_le() de de_entries) en 0xffff y hacer que el recorrido lea mucho más allá del final del bloque de metadatos de 4KB, produciendo una lectura slab fuera de límites alcanzable desde cualquier búsqueda de ruta, stat() u open() sobre un directorio indexado una vez montada la imagen. El commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during block read") ya limita dr_list para el dx_root no inline, pero dejó sin verificar la ruta inline dr_entries y el dl_list de dx_leaf. La corrección agrega la misma validación al momento de lectura para ambas listas de entradas: de_count debe ser igual a la capacidad del bloque (ocfs2_dx_entries_per_leaf()/per_root()) y de_num_used no debe superar de_count, rechazando metadatos corruptos con -EFSCORRUPTED antes de que ocfs2_dx_dir_search() pueda recorrer un arreglo de entradas fuera de rango. de_count siempre se escribe exactamente como la capacidad del bloque cuando se formatea una hoja o una raíz inline, por lo que la verificación de igualdad no rechaza ninguna imagen válida. Encontrada por las herramientas automatizadas de investigación de seguridad de 0sec (https://0sec.ai).
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a 3f28574dd59672ac47f3110c9a8ead703ec021c0 · 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a 3497aa757788de5d904f41814f1df0b292a8be09 · 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a 47b8152ed7709f7ef30b398fb0bfe4b452dd0495 · 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a aad3129b8e915d0ff492bb7517d825d8490cfdd9 · 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a 5e661f55ca8568471fce558effe81cca112f5cb2 · 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a fcfcba8fe17dbf2c8805690b8cc25e32d81249a4 · 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a b8a5c0c32df2c5b685ceef76ac77e37c7e1dc3ed · 9b7895efac906d66d19856194e1ba61f37e231a4 y anteriores a bc70726ddad53c7e9a9a85915bf2415b0d4f42f9
- Linux Afectadas: 2.6.30 No afectadas: 5.10.273 · 5.15.224 · 6.1.191 · 6.6.160 · 6.12.111 · 6.18.51
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/3f28574dd59672ac47f3110c9a8ead703ec021c0
- Referencia en git.kernel.orggit.kernel.org/stable/c/3497aa757788de5d904f41814f1df0b292a8be09
- Referencia en git.kernel.orggit.kernel.org/stable/c/47b8152ed7709f7ef30b398fb0bfe4b452dd0495
- Referencia en git.kernel.orggit.kernel.org/stable/c/aad3129b8e915d0ff492bb7517d825d8490cfdd9
- Referencia en git.kernel.orggit.kernel.org/stable/c/5e661f55ca8568471fce558effe81cca112f5cb2
- Referencia en git.kernel.orggit.kernel.org/stable/c/fcfcba8fe17dbf2c8805690b8cc25e32d81249a4
- Referencia en git.kernel.orggit.kernel.org/stable/c/b8a5c0c32df2c5b685ceef76ac77e37c7e1dc3ed
- Referencia en git.kernel.orggit.kernel.org/stable/c/bc70726ddad53c7e9a9a85915bf2415b0d4f42f9
Ver el texto original en inglés (CVE.org)
ocfs2: validate directory-index entry counts when reading metadata
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate directory-index entry counts when reading metadata ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them. ocfs2_dx_dir_search() then walks for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) dx_entry = &entry_list->de_entries[i]; over de_num_used entries with no bounds check. entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries. A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted. Commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during block read") already bounds dr_list for the non-inline dx_root, but left the inline dr_entries path and the dx_leaf dl_list unchecked. Add the same read-time validation for both entry lists: de_count must equal the capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and de_num_used must not exceed de_count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry array. de_count is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image. Found by 0sec automated security-research tooling (https://0sec.ai).