Vulnerabilidades

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: 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: 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)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: asignar EBADMSG a nfserr_io para evitar advertencias Ext4 arrojará -EBADMSG a través de ext4_readdir cuando se produzca un error de suma de comprobación, lo que dará como resultado la siguiente ADVERTENCIA. Solucione el problema asignando EBADMSG a nfserr_io. nfsd_buffered_readdir iterar_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify advertir_sin_espacio_para_csum __ advertir_sin_espacio_para_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // ADVERTENCIA [ 161.115610] ------------[ cortar aquí ]------------ [ 161.116465] nfsd: no estándar errno: -74 [ 161.117315] ADVERTENCIA: CPU: 1 PID: 780 en fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Módulos vinculados en: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd No contaminado 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Código: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 fffff52000 1c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 00000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ [161.142076] Rastreo de llamadas: [161.142575] ? __warn+0x9b/0x140 [161.143229] ? nfserrno+0x9d/0xd0 [161.143872] ? report_bug+0x125/0x150 [161.144595] ? handle_bug+0x41/0x90 [161.145284] ? exc_invalid_op+0x14/0x70 [161.146009] ? asm_exc_invalid_op+0x12/0x20 [161.146816] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? esperar_escrituras_concurrentes+0x170/0x170 [ 161.151004] ? tamaño_de_archivo_genérico_llseek+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? escritura_bytes_en_xdr_buf+0x97/0xe0 [ 161.157598] ? __escritura_bytes_en_xdr_buf+0xd0/0xd0 [ 161.158494] ? bloqueo_downgrade+0x90/0x90 [ 161.159232] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige una posible desreferencia de puntero nulo en ocfs2_set_buffer_uptodate. Al realizar una limpieza, si hay indicadores sin OCFS2_BH_READAHEAD, puede provocar una desreferencia de puntero NULL en el siguiente ocfs2_set_buffer_uptodate() si bh es NULL.