Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mt6797-mt6351: Se corrige la fuga de recuento de referencias en mt6797_mt6351_dev_probe. of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: cros_ec_codec: Se corrige la fuga de recuento de referencias en cros_ec_codec_platform_probe. of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jbd2: se corrige el error de aserción 'jh->b_frozen_data == NULL' cuando se aborta el diario El siguiente proceso fallará la aserción 'jh->b_frozen_data == NULL' en jbd2_journal_dirty_metadata(): jbd2_journal_commit_transaction unlink(dir/a) jh->b_transaction = trans1 jh->b_jlist = BJ_Metadata journal->j_running_transaction = NULL trans1->t_state = T_COMMIT unlink(dir/b) handle->h_trans = trans2 do_get_write_access jh->b_modified = 0 jh->b_frozen_data = frozen_buffer jh->b_next_transaction = trans2 jbd2_journal_dirty_metadata is_handle_aborted is_journal_aborted // devuelve falso --> jbd2 abort <-- while (commit_transaction->t_buffers) if (is_journal_aborted) jbd2_journal_refile_buffer __jbd2_journal_refile_buffer WRITE_ONCE(jh->b_transaction, jh->b_next_transaction) WRITE_ONCE(jh->b_next_transaction, NULL) __jbd2_journal_file_buffer(jh, BJ_Reserved) J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // ¡Fallo de aserción! El reproductor (ver detalles en [Enlace]) informa: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/jbd2/transaction.c:1629! código de operación no válido: 0000 [#1] PREEMPT SMP CPU: 2 PID: 584 Comm: desvincular Contaminado: GW 5.19.0-rc6-00115-g4a57a8400075-dirty #697 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202 Rastreo de llamadas: __ext4_handle_dirty_metadata+0xa0/0x290 ext4_handle_dirty_dirblock+0x10c/0x1d0 ext4_delete_entry+0x104/0x200 __ext4_unlink+0x22b/0x360 ext4_unlink+0x275/0x390 vfs_unlink+0x20b/0x4c0 do_unlinkat+0x42f/0x4c0 __x64_sys_unlink+0x37/0x50 do_syscall_64+0x35/0x80 Después de abortar el diario, se ejecuta __jbd2_journal_refile_buffer() manteniendo presionado @jh->b_state_lock. Podemos solucionarlo moviendo 'is_handle_aborted()' al área protegida por @jh->b_state_lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rxe: Corrección del error de desenrollado en rxe_create_qp(). En la función rxe_create_qp(), se llama a rxe_qp_from_init() para inicializar qp. Internamente, elementos como los bloqueos de giro no se configuran hasta rxe_qp_init_req(). Si se produce un error antes de este punto, el desenrollado llamará a rxe_cleanup() y, finalmente, a rxe_qp_do_cleanup()/rxe_cleanup_task(), lo que generará un error al intentar acceder al bloqueo de giro no inicializado. Se deben adelantar las inicializaciones de los bloqueos de giro para evitar cualquier fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: fbtft: core: establecer smem_len antes de la llamada a fb_deferred_io_init. La función fbtft_framebuffer_alloc() llama a fb_deferred_io_init() antes de inicializar info->fix.smem_len. La función framebuffer_alloc() la establece a cero. Esto activará un WARN_ON() al inicio de fb_deferred_io_init() y la función no realizará ninguna acción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/srpt: Se corrige un problema de use-after-free. Se cambian los miembros del puerto LIO dentro de struct srpt_port de miembros regulares a punteros. Se asignan las estructuras de datos del puerto LIO desde srpt_make_tport() y se liberan desde srpt_make_tport(). Se mantiene struct srpt_device mientras un puerto RDMA o un puerto de destino LIO esté asociado a él. Este parche desacopla la duración de struct srpt_port (controlado por el núcleo RDMA) y struct srpt_port_id (controlado por LIO). Este parche corrige la siguiente queja de KASAN: ERROR: KASAN: Use-After-Free en srpt_enable_tpg+0x31/0x70 [ib_srpt] Lectura de tamaño 8 en la dirección ffff888141cc34b8 por la tarea check/5093 Rastreo de llamadas: show_stack+0x4e/0x53 dump_stack_lvl+0x51/0x66 print_address_description.constprop.0.cold+0xea/0x41e print_report.cold+0x90/0x205 kasan_report+0xb9/0xf0 __asan_load8+0x69/0x90 srpt_enable_tpg+0x31/0x70 [ib_srpt] target_fabric_tpg_base_enable_store+0xe2/0x140 [target_core_mod] configfs_write_iter+0x18b/0x210 new_sync_write+0x1f2/0x2f0 vfs_write+0x3e3/0x540 ksys_write+0xbb/0x140 __x64_sys_write+0x42/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: mcp2221: evitar un desbordamiento de búfer en mcp_smbus_write() Advertencia de Smatch: drivers/hid/hid-mcp2221.c:388 Error de mcp_smbus_write(): __memcpy() '&mcp->txbuf[5]' demasiado pequeño (59 frente a 255) drivers/hid/hid-mcp2221.c:388 Error de mcp_smbus_write(): __memcpy() 'buf' demasiado pequeño (34 frente a 255) La variable 'len' puede tomar un valor entre 0 y 255, ya que puede provenir de data->block[0] y son datos de usuario. Por lo tanto, agregue una comprobación de límite para evitar un desbordamiento de búfer en memcpy().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: ipc3-topology: Impide la doble liberación de ipc_control_data mediante load_bytes. Se han realizado comprobaciones de seguridad para los controles de bytes y, si alguna falla, se libera el archivo scontrol->ipc_control_data asignado localmente, pero no se establece en NULL. En una ruta de reversión del error, el código de nivel superior también intentará liberar scontrol->ipc_control_data, lo que eventualmente provocará corrupción de memoria, ya que la doble liberación de memoria no es recomendable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio: Dividir operaciones de migración de las operaciones del dispositivo principal El núcleo vfio verifica si el controlador establece alguna operación de migración (por ejemplo, set_state/get_state) y, en consecuencia, llama a su operación. Sin embargo, actualmente el controlador mlx5 establece las operaciones anteriores sin tener en cuenta sus límites de migración. Esto puede llevar a un uso inesperado/Oops si el espacio de usuario puede llamar a las operaciones anteriores incluso si el controlador no admite la migración. Como por ejemplo, el state_mutex de migración no se inicializa en ese caso. La forma más limpia de gestionar eso parece dividir las operaciones de migración de las operaciones del dispositivo principal, esto permitirá que el controlador las configure por separado de las operaciones principales cuando sea aplicable. Como parte de eso, valide la construcción de las operaciones en el registro e incluya una comprobación para VFIO_MIGRATION_STOP_COPY ya que la uAPI afirma que debe establecerse en migration_flags. El controlador HISI también se cambió para que coincida con este esquema. Este esquema puede permitir en el futuro contar con algún grupo adicional de operaciones (por ejemplo, registro DMA) que se pueden configurar sin tener en cuenta las otras opciones en función de las capacidades del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/perf: Optimizar la limpieza del PMI pendiente y eliminar WARN_ON para la comprobación de PMI en power_pmu_disable, confirmación 2c9ac51b850d ("powerpc/perf: Corregir las devoluciones de llamada de PMU para limpiar el PMI pendiente antes de restablecer un PMC desbordado"). Se añadió la función "pmi_irq_pending" en hw_irq.h. Esta función comprueba si hay un PMI marcado como pendiente en Paca (PACA_IRQ_PMI). Se utiliza en power_pmu_disable en un WARN_ON. El objetivo es emitir una advertencia si hay un PMI pendiente, pero no se encuentra ningún contador desbordado. Durante algunas ejecuciones de rendimiento, se muestra la siguiente advertencia: ADVERTENCIA: CPU: 36 PID: 0 en arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Módulos vinculados: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Rastreo de llamadas: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 Esto significa que no hay ningún PMC desbordado entre los eventos activos en la PMU, pero hay una PMU pendiente en Paca. La función "any_pmc_overflown" comprueba los PMC en los eventos activos en cpuhw->n_events. Fragmento de código: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Aquí, el PMC desbordado no proviene del evento activo. Ejemplo: Al realizar un registro de rendimiento, los ciclos e instrucciones predeterminados se ejecutarán en PMC6 y PMC5 respectivamente. Podría ocurrir que el evento desbordado no esté activo y que el PMI pendiente corresponda al evento inactivo. Registros de depuración de trace_printk: <<>> any_pmc_overflown: idx es 5: el valor de pmc es 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Aquí, el PMC activo (de idx) es PMC5, pero el PMC desbordado es PMC6(0x80002011). Cuando manejamos la interrupción de PMI para tales casos, si el PMC desbordado proviene de un evento inactivo, será ignorado. Referencia de confirmación: confirmación bc09c219b2e6 ("powerpc/perf: Corrección de encontrar PMC desbordado en la interrupción") El parche aborda dos cambios: 1) Corrección 1: Eliminación de la advertencia ( WARN_ON(pmi_irq_pending()); ) Estábamos imprimiendo una advertencia si no se encontraba ningún PMC desbordado entre los eventos PMU activos, pero sí PMI pendiente en PACA. Pero esto podría suceder en casos donde el PMC desbordado no está en el PMC activo. Un evento inactivo podría haber causado el desbordamiento. Por lo tanto, la advertencia no es necesaria. Para saber si el PMI pendiente proviene de un evento inactivo, necesitamos recorrer todos los PMC, lo que causará más lecturas de SPR a través de mfspr y aumentará el cambio de contexto. Además, en la función existente: --- truncado ---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rpmsg: Se corrige una posible fuga de recuento en rpmsg_register_device_override(). rpmsg_register_device_override necesita llamar a put_device para liberar vch cuando driver_set_override falla. Se soluciona añadiendo put_device() a la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: imx_rproc: Se corrige la fuga de refcount en imx_rproc_addr_init. of_parse_phandle() devuelve un puntero de nodo con refcount incrementado; debemos usar of_node_put() cuando ya no sea necesario. Esta función tiene dos rutas que faltan en of_node_put().