Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige el índice fuera de los límites en la traducción del formato de hardware degamma de DCN30. Esta confirmación aborda un posible problema de índice fuera de los límites en la función `cm3_helper_translate_curve_to_degamma_hw_format` en el módulo de administración de color DCN30. El problema podría ocurrir cuando el índice 'i' excede la cantidad de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La corrección agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.blue' 1025 <= s32max

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar use after free en ext4_ext_show_leaf() En ext4_find_extent(), path puede liberarse por error o reasignarse, por lo que el uso de un *ppath previamente guardado puede haberse liberado y, por lo tanto, puede activar el use after free, de la siguiente manera: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent no puede liberar path // pero la puesta a cero tiene éxito ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // use after free de path !!! De manera similar a ext4_split_extent_at(), usamos *ppath directamente como entrada para ext4_ext_show_leaf(). Por cierto, corrige un error ortográfico. El mismo problema en ext4_ext_handle_unwritten_extents(). Dado que 'path' solo se usa en ext4_ext_show_leaf(), elimine 'path' y use *ppath directamente. Este problema se activa solo cuando se define EXT_DEBUG y, por lo tanto, no afecta la funcionalidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: asegúrese de que fw_info no sea nulo antes de usarlo Esto resuelve la advertencia de valor de retorno nulo desreferenciado informada por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: inicializar el valor predeterminado de get_bytes_per_element en 1. Las variables, utilizadas como denominadores y que quizás no se asignen a otros valores, no deben ser 0. bytes_per_element_y y bytes_per_element_c se inicializan mediante get_bytes_per_element(), que nunca debe devolver 0. Esto corrige 10 problemas de DIVIDE_BY_ZERO informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrige el índice fuera de los límites en la traducción del formato de hardware degamma Corrige el problema del índice fuera de los límites en la función `cm_helper_translate_curve_to_degamma_hw_format`. El problema podría ocurrir cuando el índice 'i' excede el número de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La corrección agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.blue' 1025 <= s32max

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar use-after-free en ext4_ext_insert_extent() Como mencionó Ojaswin en Link, en ext4_ext_insert_extent(), si la ruta se reasigna en ext4_ext_create_new_leaf(), usaremos la ruta obsoleta y causaremos UAF. A continuación, se muestra un seguimiento de muestra con valores ficticios: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* aquí la ruta sigue siendo 2000, UAF! */ eh = path[depth].p_hdr ===================================================================== ERROR: KASAN: slab-use-after-free en ext4_ext_insert_extent+0x26d4/0x3330 Lectura de tamaño 8 en la dirección ffff8881027bf7d0 por la tarea kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 No contaminado 6.11.0-rc2-dirty #866 Seguimiento de llamadas: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Asignado por la tarea 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Liberado por la tarea 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...]================================================================== Así que use *ppath para actualizar el path para evitar el problema de arriba

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de slab-use-after-free en ext4_split_extent_at() Nos topamos con el siguiente use after free: ====================================================================== ERROR: KASAN: slab-use-after-free en ext4_split_extent_at+0xba8/0xcc0 Lectura de tamaño 2 en la dirección ffff88810548ed08 por la tarea kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 No contaminado 6.9.0-dirty #724 Seguimiento de llamadas: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Asignado por la tarea 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Liberado por la tarea 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================== El flujo de activación del problema es el siguiente: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // devuelve -ENOMEM o -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. Si err es -ENOMEM: ext4_ext_dirty(path + path->p_depth) // ¡¡¡path use after free!!! b. Si err es -EIO y tenemos EXT_DEBUG definido: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // ¡¡¡La ruta también es use after free!!! Por lo tanto, cuando intente poner a cero o corregir la longitud de la extensión, llame a ext4_find_extent() para actualizar la ruta. Además, usamos *ppath directamente como una entrada de ext4_ext_show_leaf() para evitar un posible use after free cuando se define EXT_DEBUG y para evitar actualizaciones de ruta innecesarias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de un problema en alloc_flex_gd() Wesley informó de un problema: ======================================================================= EXT4-fs (dm-5): cambio de tamaño del sistema de archivos de 7168 a 786432 bloques ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs No contaminado 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Rastreo de llamadas: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e == ... Tome n=0,flexbg_size=16 como ejemplo: last:15 |o---------------|--------------n-| o_group:0 redimensionar a n_group:30 El reproductor correspondiente es: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Elimine el problema más 1 para solucionar el problema y agregue un WARN_ON_ONCE() para evitar que el problema vuelva a ocurrir. [ Nota: otro reprocesador que esta confirmación corrige es: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: omapdrm: Agregar comprobación faltante para alloc_ordered_workqueue, ya que puede devolver un puntero NULL y provocar una desreferencia del puntero NULL. Agregar comprobación para el valor de retorno de alloc_ordered_workqueue.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: actualización de orig_path en ext4_find_extent() En ext4_find_extent(), si la ruta no es lo suficientemente grande, la liberamos y establecemos *orig_path en NULL. Pero después de reasignar e inicializar correctamente la ruta, no actualizamos *orig_path, en cuyo caso el llamador obtiene una ruta válida pero un ppath NULL, y esto puede causar una desreferencia de puntero NULL o una pérdida de memoria de ruta. Por ejemplo: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // ¡Desreferencia de puntero NULL! ===================================================================== ERROR: Desreferencia de puntero NULL del núcleo, dirección: 000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress No contaminado 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Rastreo de llamada: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ====================================================================== Por lo tanto, *orig_path se actualiza cuando la búsqueda de extensión tiene éxito, de modo que el llamador puede usar path o *ppath de forma segura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corregir el doble brelse() del búfer de la ruta de las extensiones En ext4_ext_try_to_merge_up(), establezca path[1].p_bh en NULL después de que se haya liberado, de lo contrario, puede liberarse dos veces. Un ejemplo de lo que desencadena esto es el siguiente: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. hacer split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // devuelve -ENOMEM |// obtiene el error e intenta poner a cero |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> no establecido en NULL aquí |// puesta a cero exitosa // 2. actualizar ruta ext4_find_extent // 3. hacer split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh sigue siendo el valor anterior ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse un buffer dos veces Finalmente obtuve la siguiente ADVERTENCIA al eliminar el buffer de lru: =============================================== VFS: brelse: Intentando liberar búfer libre ADVERTENCIA: CPU: 2 PID: 72 en fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 No contaminado 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Seguimiento de llamadas: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: corregir UAF en torno a la destrucción de cola Actualmente hacemos cosas como poner en cola el paso de destrucción final en un wq de sistema aleatorio, que sobrevivirá a la instancia del controlador. Con un mal momento, podemos desmantelar el controlador con una o más colas de trabajo de trabajo aún activas, lo que genera varios splats de UAF. Agregue un paso fini para garantizar que las colas de usuario se desmantelen correctamente. En este punto, GuC ya debería estar destruido, por lo que la cola en sí ya no debería ser referenciada desde el punto de vista del hardware. v2 (Matt B): parece mucho más seguro usar una cola de espera y luego simplemente esperar a que xa_array se vacíe antes de activar el drenaje. (seleccionado de el commit 861108666cc0e999cffeab6aff17b662e68774e3)