Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: vmalloc: garantizar que vmap_block se inicialice antes de agregarlo a la cola. El commit 8c61291fd850 ("mm: corregir referencia vbq incorrecta en purge_fragmented_block") extendió la estructura 'vmap_block' para que contenga un campo 'cpu' que se establece en el momento de la asignación en el id de la CPU que se inicializa. Cuando se crea una instancia de 'vmap_block' mediante new_vmap_block(), la estructura parcialmente inicializada se agrega a la matriz x local 'vmap_block_queue' antes de que se haya inicializado el campo 'cpu'. Si otra CPU está recorriendo simultáneamente la matriz x (por ejemplo, a través de vm_unmap_aliases()), puede realizar un acceso fuera de los límites a la cola remota gracias a un índice no inicializado. Esto se ha observado como errores UBSAN en Android: | Error interno: UBSAN: índice de matriz fuera de los límites: 00000000f2005512 [#1] PREEMPT SMP | | Rastreo de llamadas: | purge_fragmented_block+0x204/0x21c | _vm_unmap_aliases+0x170/0x378 | vm_unmap_aliases+0x1c/0x28 | change_memory_common+0x1dc/0x26c | set_memory_ro+0x18/0x24 | module_enable_ro+0x98/0x238 | do_init_module+0x1b0/0x310 Mueva la inicialización de 'vb->cpu' en new_vmap_block() antes de la adición a la matriz x.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Evitar la ejecución entre dcn35_set_drr() y dc_state_destruct() dc_state_destruct() anula el contexto de recurso del estado del DC. El contexto de tubería pasado a dcn35_set_drr() es un miembro de este contexto de recurso. Si se llama a dc_state_destruct() en paralelo al procesamiento de IRQ (que llama a dcn35_set_drr() en algún momento), podemos terminar usando campos de devolución de llamada de función ya anulados de struct stream_resource. La lógica en dcn35_set_drr() ya intenta evitar esto, al comprobar tg contra NULL. Pero si la anulación ocurre exactamente después de la comprobación de NULL y antes del siguiente acceso, entonces obtenemos una ejecución. Evite esto copiando tg primero a una variable local y luego use esta variable para todas las operaciones. Esto debería funcionar, siempre y cuando nadie libere el grupo de recursos donde se encuentran los generadores de tiempo. (seleccionado de el commit 0607a50c004798a96e62c089a4c34c220179dcb5)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Evitar la ejecución entre dcn10_set_drr() y dc_state_destruct() dc_state_destruct() anula el contexto de recurso del estado del DC. El contexto de tubería pasado a dcn10_set_drr() es un miembro de este contexto de recurso. Si se llama a dc_state_destruct() en paralelo al procesamiento de IRQ (que llama a dcn10_set_drr() en algún momento), podemos terminar usando campos de devolución de llamada de función ya anulados de struct stream_resource. La lógica en dcn10_set_drr() ya intenta evitar esto, al comprobar tg contra NULL. Pero si la anulación ocurre exactamente después de la comprobación de NULL y antes del siguiente acceso, entonces obtenemos una ejecución. Evite esto copiando tg primero a una variable local y luego use esta variable para todas las operaciones. Esto debería funcionar, siempre y cuando nadie libere el grupo de recursos donde se encuentran los generadores de tiempo. (seleccionado de el commit a3cc326a43bdc48fbdf53443e1027a03e309b643)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no BUG_ON en ENOMEM desde btrfs_lookup_extent_info() en walk_down_proc(). Aquí manejamos los errores correctamente, ENOMEM no es fatal, devuelve el error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: limpia nuestro manejo de refs == 0 en la eliminación de instantáneas En reada tenemos BUG_ON(refs == 0), lo que podría ser desagradable ya que no estamos manteniendo un bloqueo en la hoja de extensión y, por lo tanto, podríamos obtener una respuesta incorrecta transitoria. En walk_down_proc también tenemos BUG_ON(refs == 0), lo que podría suceder si tenemos corrupción del árbol de extensión. Cambia eso para que devuelva -EUCLEAN. En do_walk_down() capturamos este caso y lo manejamos correctamente, sin embargo, devolvemos -EIO, que -EUCLEAN es un código de error más apropiado. Finalmente, en walk_up_proc tenemos el mismo BUG_ON(refs == 0), así que conviértelo en un manejo de errores adecuado. También ajusta el mensaje de error para que podamos hacer algo con la información.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: line: always fill *error_out in setup_one_line() El puntero no es inicializado por los llamadores, pero he encontrado casos en los que aún se imprime; inicialícelo en todos los casos posibles en setup_one_line().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: rockchip: Resolver el manejo desequilibrado de PM en tiempo de ejecución / PM del sistema el commit e882575efc77 ("spi: rockchip: Suspender y reanudar el bus durante las operaciones NOIRQ_SYSTEM_SLEEP_PM") dejó de respetar el estado de PM en tiempo de ejecución y simplemente deshabilitó los relojes incondicionalmente al suspender el sistema. Esto causa problemas cuando el dispositivo ya está suspendido en tiempo de ejecución cuando nos vamos a dormir, en cuyo caso deshabilitamos dos veces los relojes y generamos una ADVERTENCIA. Vuelva a pm_runtime_force_{suspend,resume}(), porque eso todavía parece lo correcto y el commit mencionado anteriormente no explica por qué dejó de usarlo. Además, refactorice parte del manejo de errores de resume(), porque en realidad no es una buena idea volver a deshabilitar los relojes en caso de falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel: Limitar el período en Haswell La ejecución de la prueba ltp cve-2015-3290 al mismo tiempo informa las siguientes advertencias. perfevents: ¡bucle irq atascado! ADVERTENCIA: CPU: 31 PID: 32438 en arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Rastreo de llamadas: ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Gracias al análisis de Thomas Gleixner, el problema es causado por el bajo período inicial (1) del algoritmo de estimación de frecuencia, que desencadena los defectos del HW, específicamente las erratas HSW11 y HSW143. (Para conocer los detalles, consulte https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) El HSW11 requiere un período mayor a 100 para el evento INST_RETIRED.ALL, pero el período inicial en el modo freq es 1. La errata es la misma que la del BDM11, que ha sido compatible con el kernel. También se aplica un período mínimo de 128 en HSW. HSW143 se refiere a que el contador fijo 1 puede sobrecontar 32 con Hyper-Threading habilitado. Sin embargo, según la prueba, el hardware tiene más problemas de los que indica. Además del contador fijo 1, se puede observar el mensaje "la interrupción tardó demasiado" en cualquier contador que se haya armado con un período <32 y dos eventos hayan expirado en el mismo NMI. Se aplica un período mínimo de 32 para el resto de los eventos. El código de workaround recomendado del HSW143 no está implementado. Porque solo soluciona el problema del contador fijo. Implica una sobrecarga adicional a través de la escritura adicional del MSR. Hasta el momento, no se ha informado de ningún problema de conteo excesivo relacionado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: meson: axg-card: se corrige el problema 'use-after-free'. El búfer 'card->dai_link' se reasigna en 'meson_card_reallocate_links()', por lo que se mueve la inicialización del puntero 'pad' después de esta función cuando la memoria ya está reasignada. Informe de error de Kasan: ===================================================================== ERROR: KASAN: slab-use-after-free en axg_card_add_link+0x76c/0x9bc Lectura de tamaño 8 en la dirección ffff000000e8b260 por la tarea modprobe/356 CPU: 0 PID: 356 Comm: modprobe Contaminado: GO 6.9.12-sdkernel #1 Rastreo de llamadas: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 registro_controlador+0xa8/0x1e8 __registro_controlador_plataforma+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] hacer_una_llamada_inicio+0xdc/0x25c hacer_módulo_inicio+0x10c/0x334 cargar_módulo+0x24c4/0x26cc módulo_inicio_desde_archivo+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invocar_llamada_al_sistema+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c hacer_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: heaps: Fix off-by-one in CMA heap fault handler Hasta que se agregó VM_DONTEXPAND en el commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") era posible obtener un mapeo más grande que el tamaño del buffer a través de mremap y omitir la verificación de desbordamiento en dma_buf_mmap_internal. Al usar dicho mapeo para intentar fallar más allá del final del búfer, el manejador de fallas del montón de CMA también verifica el desplazamiento de la falla contra el tamaño del búfer, pero obtiene el límite incorrecto por 1. Corrija la verificación del límite para que no leamos el final de la matriz de páginas e insertemos una página arbitraria en el mapeo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: nxp-fspi: solucione el error de informe fuera de los límites de KASAN Cambie la longitud de memcpy para solucionar el problema de fuera de los límites al escribir datos que no están alineados con 4 bytes en TX FIFO. Para reproducir el problema, escriba datos de 3 bytes en el chip NOR. dd if=3b of=/dev/mtd0 [ 36.926103] ====================================================================== [ 36.933409] ERROR: KASAN: slab fuera de límites en nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Lectura de tamaño 4 en la dirección ffff00081037c2a0 por la tarea dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd No contaminado 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Nombre del hardware: Freescale i.MX8QM MEK (DT) [ 36.961260] Rastreo de llamadas: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invocar_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Asignado por la tarea 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoque_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] La dirección con errores pertenece al objeto en ffff00081037c2a0 [ 37.128977] que pertenece al caché kmalloc-8 de tamaño 8 [ 37.141177] La dirección con errores se encuentra a 0 bytes dentro de la [ 37.141177] región asignada de 3 bytes [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] La dirección con errores pertenece a la página física: [ 37.160559] página: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] indicadores: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] página volcada porque: kasan: se detectó un acceso incorrecto [ 37.200144] [ 37.201647] Estado de la memoria alrededor de la dirección con errores: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] 081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ===================================================== ========== ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: usar IWL_FW_CHECK para verificar el ID del enlace La función de búsqueda iwl_mvm_rcu_fw_link_id_to_link_conf() normalmente se llama con la entrada del firmware, por lo que debería usar IWL_FW_CHECK() en lugar de WARN_ON().