Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: mt8173: Se corrige la fuga de refcount en mt8173_rt5650_rt5676_dev_probe. of_parse_phandle() devuelve un puntero de nodo con refcount incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se corrige la ausencia de of_node_put() en las rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: mt8173-rt5650: Se corrige la fuga de recuento de referencias en mt8173_rt5650_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 corrige la fuga de recuento de referencias en algunas rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: k3-r5: Se corrige la fuga de recuento de referencias en k3_r5_cluster_of_init. Cada iteración de for_each_available_child_of_node() disminuye el recuento de referencias del nodo anterior. Al interrumpir un bucle for_each_available_child_of_node() antes de tiempo, debemos llamar explícitamente a of_node_put() en el nodo hijo. Añada la falta de of_node_put() para evitar la fuga de recuento de referencias.

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().

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: 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: 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: tty: n_gsm: corrige el bloqueo y la inanición del enlace en la ruta de datos de salida La implementación actual pone en cola nuevos paquetes de control y de usuario según sea necesario y procesa esta cola hasta el ldisc en la misma ruta de código. Eso significa que las capas superior e inferior están acopladas rígidamente en el código. Debido a esto, pueden ocurrir bloqueos como se ve a continuación mientras se transmiten datos, especialmente durante la congestión del ldisc. Además, los canales de datos privan al canal de control en una carga de transmisión alta en el ldisc. Introduzca una cola de datos de canal de control adicional para evitar tiempos de espera y cuelgues de enlace durante la congestión del ldisc. Esto se procesa antes que la cola de datos del canal de usuario en gsm_data_kick(), es decir, con la máxima prioridad. Coloque la cola a la ruta de datos del ldisc en una cola de trabajo y actívela siempre que se hayan incluido nuevos datos en la cola de transmisión. Modifique gsm_dlci_data_sweep() según corresponda para llenar la cola de transmisión hasta TX_THRESH_HI. Esto soluciona el problema de bloqueo, mantiene baja la latencia y proporciona un buen rendimiento con una carga de datos alta. Tenga en cuenta que ahora todos los paquetes de un DLCI se eliminan de la cola interna si el DLCI asociado estaba cerrado. Esto garantiza que la tarea de escritura introducida no envíe datos a un DLCI ya cerrado. ERROR: recursión de spinlock en CPU#0, test_v24_loop/124 bloqueo: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Contaminado: GO 5.18.0-rc2 #3 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL ---truncado---

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: net: 9p: se corrige la fuga de recuento de referencias en el manejo de errores de p9_read_work(). Es necesario llamar a p9_req_put cuando m->rreq->rc.sdata es NULL para evitar una fuga temporal de recuento de referencias. [Dominique: ajustes en la redacción de las confirmaciones, correcciones del argumento p9_req_put para la rebase]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige la pérdida de memoria al usar fscache. Si se da el caso 'index == next_cached', se filtra un recuento de referencias en la página de estructura. Para solucionar esto, use readahead_folio(), que se encarga del recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: sp5100_tco: corrige una pérdida de memoria del recurso EFCH MMIO A diferencia de release_mem_region(), una llamada a release_resource() no libera el recurso, por lo que debe liberarse explícitamente para evitar una pérdida de memoria.