Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar phantom_stream antes de usarlo dcn32_enable_phantom_stream puede devolver un valor nulo, por lo que se debe comprobar el valor devuelto antes de usarlo. Esto soluciona 1 problema de NULL_RETURNS informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar variables inicializadas en valores nulos [QUÉ Y CÓMO] drr_timing y subvp_pipe se inicializan en valores nulos y no siempre se les asignan nuevos valores. Es necesario comprobar si hay valores nulos antes de desreferenciar. Esto soluciona 2 problemas de FORWARD_NULL informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Inicializar el valor predeterminado de los denominadores en 1 [QUÉ Y CÓMO] Las variables utilizadas como denominadores y que quizás no estén asignadas a otros valores, no deben ser 0. Cambie su valor predeterminado a 1 para que nunca sean 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: comprobar el flujo antes de compararlo [QUÉ Y CÓMO] amdgpu_dm puede pasar un flujo nulo a dc_is_stream_unchanged. Es necesario comprobar si hay valores nulos antes de desreferenciarlos. Esto soluciona 1 problema FORWARD_NULL informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Se corrige el acceso a uninit-value de new_ea en ea_buffer syzbot informa que lzo1x_1_do_compress está usando uninit-value: ========================================================= ERROR: KMSAN: uninit-value en lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit se almacenó en la memoria en: ea_put fs/jfs/xattr.c:639 [en línea] ... La variable local ea_buf se creó en: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ========================================================== El motivo es que ea_buf->new_ea no se inicializa correctamente. Solucione esto usando memset para vaciar su contenido al principio en ea_get().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: comprobar si leafidx es mayor que la cantidad de hojas por árbol dmap syzbot informa que dbSplit está fuera de los límites, esto se debe a que dmt_leafidx es mayor que la cantidad de hojas por árbol dmap, se agrega una verificación para dmt_leafidx en dbFindLeaf. Shaggy: Se modificó la verificación de cordura para que se aplique a las páginas de control y a las páginas de hoja.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Corrección de uaf en dbFreeBits [informado por syzbot] ====================================================================== ERROR: KASAN: slab-use-after-free en __mutex_lock_common kernel/locking/mutex.c:587 [en línea] ERROR: KASAN: slab-use-after-free en __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Lectura de tamaño 8 en la dirección ffff8880229254b0 por la tarea syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 No contaminado 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [en línea] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [en línea] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Liberado por la tarea 5218: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2252 [en línea] slab_free mm/slub.c:4473 [en línea] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [en línea] vfs_fsconfig_locked fs/fsopen.c:292 [en línea] __do_sys_fsconfig fs/fsopen.c:473 [en línea] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Análisis] Hay dos rutas (dbUnmount y jfs_ioc_trim) que generan una condición de ejecución al acceder a bmap, lo que lleva a la ocurrencia de uaf. Utilice el bloqueo s_umount para sincronizarlas, a fin de evitar uaf causado por una condición de ejecución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, slub: evitar poner a cero la zona roja de kmalloc Desde el commit 946fa0dbf2d8 ("mm/slub: extender la comprobación de la zona roja a espacio de kmalloc asignado adicional al solicitado"), al establecer orig_size se trata el espacio desperdiciado (object_size - orig_size) como una zona roja. Sin embargo, con init_on_free=1 borramos todo el objeto->size, incluida la zona roja. Además, borramos los metadatos del objeto, incluido el orig_size almacenado, haciéndolo cero, lo que hace que check_object() trate todo el objeto como una zona roja. Estos problemas conducen al siguiente informe de ERROR con "slub_debug=FUZ init_on_free=1": [ 0.000000] ===================================================================================== [ 0.000000] ERROR kmalloc-8 (no contaminado): kmalloc Redzone sobrescrito [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. Primer byte 0x0 en lugar de 0xcc [ 0.000000] CORREGIR kmalloc-8: Restaurando kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Losa 0xfffffdffc0400c80 objetos=36 usados=23 fp=0xffff000010032a18 indicadores=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Objeto 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Objeto ffff000010032858: cc cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc cc ........ [ 0.000000] Relleno ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: intercambiador/0 No contaminado 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Nombre del hardware: Placa NXP i.MX95 19X19 (DT) [ 0.000000] Rastreo de llamadas: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec Para solucionar el problema, use orig_size para limpiar el área usada. Y restaure el valor de orig_size después de limpiar el área restante. Cuando CONFIG_SLUB_DEBUG no está definido, (get_orig_size()' retorna directamente s->object_size. Entonces, cuando se usa memset para inicializar el área, el tamaño puede ser simplemente orig_size, ya que orig_size retorna object_size cuando CONFIG_SLUB_DEBUG no está habilitado. Y orig_size nunca puede ser mayor que object_size.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para que el sistema no entre en pánico por falta de inyección de segmento libre f2fs: corrección para que el sistema no entre en pánico por falta de inyección de segmento libre syzbot informa un error de f2fs como el siguiente: F2FS-fs (loop0): no inyecta ningún segmento libre en get_new_segment de __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): sistema de archivos detenido debido a la razón: 7 ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 No contaminado 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [en línea] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Rastreo de llamadas: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [en línea] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [en línea] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [en línea] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 La causa raíz es cuando no inyectamos un fallo de segmento libre en f2fs, no deberíamos hacer que el sistema entre en pánico, arréglelo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: soluciona un problema de desbordamiento de sdiv Zac Ecob informó de un problema en el que un programa bpf puede provocar un fallo del kernel debido al siguiente error: Oops: error de división: 0000 [#1] PREEMPT SMP KASAN PTI El fallo se debe a la siguiente división con signo: LLONG_MIN/-1 donde LLONG_MIN equivale a -9.223.372.036.854.775.808. Se supone que LLONG_MIN/-1 da un número positivo 9.223.372.036.854.775.808, pero es imposible ya que para sistemas de 64 bits, el número positivo máximo es 9.223.372.036.854.775.807. En x86_64, LLONG_MIN/-1 provocará una excepción del kernel. En arm64, el resultado para LLONG_MIN/-1 es LLONG_MIN. Una investigación más profunda encontró que todos los siguientes casos de sdiv/smod pueden activar una excepción cuando el programa bpf se ejecuta en la plataforma x86_64: - LLONG_MIN/-1 para operación de 64 bits - INT_MIN/-1 para operación de 32 bits - LLONG_MIN%-1 para operación de 64 bits - INT_MIN%-1 para operación de 32 bits donde -1 puede ser inmediato o en un registro. En arm64, no hay excepciones: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 donde -1 puede ser inmediato o en un registro. Se necesita aplicar un parche a Insn para manejar los casos anteriores y los códigos parcheados produjeron resultados alineados con el resultado de arm64 anterior. Los siguientes son pseudocódigos para manejar excepciones sdiv/smod incluyendo tanto el divisor -1 como el divisor 0 y el divisor se almacena en un registro. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // solo cuando !is64 L3: wY = wY // solo cuando !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar stream_status antes de usarlo [QUÉ Y CÓMO] dc_state_get_stream_status puede devolver null y, por lo tanto, debe comprobarse null antes de usar stream_status. Esto soluciona 1 problema de NULL_RETURNS informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Validar punteros hdwq antes de desreferenciar en rutas de reinicio/errata Cuando el HBA está experimentando un reinicio o está manejando un evento de erratas, pueden ocurrir fallos de desreferencia de ptr NULL en rutinas como lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk() o lpfc_abort_handler(). Agregue verificaciones de ptr NULL antes de desreferenciar punteros hdwq que pueden haberse liberado debido a operaciones que colisionan con un controlador de eventos de reinicio o erratas.