Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Prueba del campo "silence" en la estructura "pcm_format_data" Syzbot informa "KASAN: null-ptr-deref Write in snd_pcm_format_set_silence".[1] Se debe a la falta de validación del campo "silence" de la estructura "pcm_format_data" en la matriz "pcm_formats". Agregue una prueba para "pat" válido y, si no lo es, devuelva -EINVAL. [1] https://lore.kernel.org/lkml/000000000000d188ef05dc2c7279@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ep93xx: clock: Arreglar UAF en ep93xx_clk_register_gate() arch/arm/mach-ep93xx/clock.c:154:2: advertencia: Uso de memoria después de que se libera [clang-analyzer-unix.Malloc] arch/arm/mach-ep93xx/clock.c:151:2: nota: Tomando rama verdadera si (IS_ERR(clk)) ^ arch/arm/mach-ep93xx/clock.c:152:3: nota: Se libera memoria kfree(psc); ^~~~~~~~~~ arch/arm/mach-ep93xx/clock.c:154:2: nota: Uso de memoria después de que se libera return &psc->hw; ^ ~~~~~~~~

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: dev: verificar el valor de retorno al llamar a dev_set_name() Si dev_set_name() falla, dev_name() es nulo, verifique el valor de retorno de dev_set_name() para evitar el null-ptr-deref.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: se corrige una posible pérdida de memoria en gpu_metrics_table La memoria está asignada para gpu_metrics_table en renoir_init_smc_tables(), pero no se libera en int smu_v12_0_fini_smc_tables(). ¡Libérenla!

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: davinci: vpif: fix use-after-free on driver unbind El controlador asigna y registra dos estructuras de dispositivos de plataforma durante la sonda, pero los dispositivos nunca se anularon el registro en la anulación del enlace del controlador. Esto da como resultado un use-after-free en la anulación del enlace del controlador, ya que las estructuras de dispositivos se asignaron utilizando devres y serían liberadas por el núcleo del controlador cuando remove() regrese. Solucione esto agregando las llamadas de anulación de registro faltantes a la devolución de llamada remove() y haciendo que la sonda falle en los errores de registro. Tenga en cuenta que las estructuras de dispositivos de plataforma se deben liberar utilizando una devolución de llamada de liberación adecuada para evitar filtrar recursos asociados, como nombres de dispositivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: samples/landlock: Se corrige la pérdida de memoria de path_list El análisis estático de Clang informa este error sandboxer.c:134:8: advertencia: Posible pérdida de memoria señalada por 'path_list' ret = 0; ^ path_list se asigna en parse_path() pero nunca se libera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: vdec: se ha corregido un posible problema de pérdida de memoria La implementación de venus_helper_alloc_dpb_bufs() permite un retorno temprano a una ruta de error al verificar el id de ida_alloc_min(), lo que no liberaría la asignación de búfer anterior. Mueva el kfree() directo de la verificación de errores de dma_alloc_attrs() a la ruta de error común para garantizar que se liberen las asignaciones en todas las rutas de error en esta función. Addresses-Coverity: 1494120 ("Fuga de recursos")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: se corrige el use-after-free en jffs2_clear_xattr_subsystem Cuando montamos una imagen jffs2, asumimos que los primeros bloques de la imagen son normales y contienen al menos un inodo relacionado con xattr, pero el siguiente bloque es anormal. Como resultado, se devuelve un error en jffs2_scan_eraseblock(). Luego se llama a jffs2_clear_xattr_subsystem() en jffs2_build_filesystem() y luego nuevamente en jffs2_do_fill_super(). Finalmente podemos observar el siguiente reporte: ======================================================================= ERROR: KASAN: use-after-free en jffs2_clear_xattr_subsystem+0x95/0x6ac Lectura de tamaño 8 en la dirección ffff8881243384e0 por la tarea mount/719 Rastreo de llamadas: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Asignado por la tarea 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] Liberado por la tarea 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] La dirección con errores pertenece al objeto en ffff8881243384b8 que pertenece al caché jffs2_xattr_ref de tamaño 48 La dirección con errores se encuentra 40 bytes dentro de la región de 48 bytes [ffff8881243384b8, ffff8881243384e8) [...] ========================================================================== La activación del ERROR se muestra en la siguiente pila: ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again ----------------------------------------------------------- Se devuelve un error en jffs2_do_mount_fs(). Si jffs2_sum_init() devuelve el error, no es necesario ejecutar jffs2_clear_xattr_subsystem(). Si jffs2_build_filesystem() devuelve el error, tampoco es necesario volver a ejecutar jffs2_clear_xattr_subsystem(). Por lo tanto, mueva jffs2_clear_xattr_subsystem() de 'out_inohash' a 'out_root' para solucionar este problema de UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/virtio: Asegúrese de que objs no sea NULL en virtio_gpu_array_put_free() Si virtio_gpu_object_shmem_init() falla (por ejemplo, debido a la inyección de fallos, como sucedió en el informe de error de syzbot), se podría llamar a virtio_gpu_array_put_free() con objs igual a NULL. Asegúrese de que objs no sea NULL en virtio_gpu_array_put_free() o, de lo contrario, regrese de la función.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: se corrige una posible pérdida de memoria en gpu_metrics_table La memoria está asignada para gpu_metrics_table en renoir_init_smc_tables(), pero no se libera en int smu_v12_0_fini_smc_tables(). ¡Libérenla!

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/plane: mover la comprobación de rango para format_count antes Si bien la comprobación para format_count > 64 en __drm_universal_plane_init() no debería verse afectada (es un WARN_ON), en su posición actual perderá la matriz plane->format_types y no podrá llamar a drm_mode_object_unregister(), lo que filtra el identificador modeset. Muévalo al inicio de la función para evitar asignar esos recursos en primer lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se han solucionado algunas fugas de memoria en una ruta de manejo de errores de 'log_replay()'. Todas las rutas de manejo de errores conducen a 'out', donde se liberan muchos recursos. Hágalo también aquí en lugar de un retorno directo, de lo contrario, se producirán fugas de 'log', 'ra' y 'log->one_page_buf' (al menos).