Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexión: no acceder a req_list mientras se está manipulando. El mutex icc_lock se dividió en mutex icc_lock e icc_bw_lock separados en [1] para evitar símbolos de bloqueo. Sin embargo, esto no protegió adecuadamente el acceso a icc_node::req_list. La función icc_set_bw() eventualmente iterará sobre req_list mientras solo mantiene icc_bw_lock, pero req_list se puede modificar mientras solo mantiene icc_lock. Esto provoca ejecucións entre icc_set_bw(), of_icc_get() e icc_put(). Ejemplo A: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(ruta_b) mutex_lock(&icc_lock); agregado_requests() hlist_for_each_entry(r, ... hlist_del(... Ejemplo B: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index( ) mutex_lock(&icc_lock); path_find() path_init() agregado_requests() hlist_for_each_entry(r, ... hlist_add_head(... Solucione este problema asegurándose de que icc_bw_lock siempre se mantenga antes de manipular icc_node::req_list. El adicional Los lugares donde se mantiene icc_bw_lock no realizan ninguna asignación de memoria, por lo que aún deberíamos estar a salvo de los símbolos de bloqueo originales que motivaron los bloqueos separados [1] commit af42269c3523 ("interconexión: arreglar el bloqueo para runpm vs reclaim")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: sysfs: corrige la fuga de referencia en sysfs_break_active_protection() La rutina sysfs_break_active_protection() tiene una fuga de referencia obvia en su ruta de error. Si la llamada a kernfs_find_and_get() falla, entonces kn será NULL, por lo que no se llamará a la rutina complementaria sysfs_unbreak_active_protection() (y solo causaría una infracción de acceso al intentar eliminar la referencia a kn->parent si se llamara). Como resultado, la referencia a kobj adquirida al inicio de la función nunca se publicará. Solucione la fuga agregando una llamada explícita a kobject_put() cuando kn sea NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: corrija el recuento de PDO en pd_set Los errores off-by-one ocurren porque nr_snk_pdo y nr_src_pdo se agregaron incorrectamente. El índice del bucle es igual al número de PDO que se actualizarán al salir del bucle y no es necesario agregar uno. Al realizar la negociación de energía, TCPM se basa en "nr_snk_pdo" como el tamaño de la matriz de PDO del receptor local para que coincida con las capacidades de origen del puerto asociado. Si se produce un desbordamiento de uno a uno, es posible que se envíe un RDO incorrecto y que se produzca una transferencia de energía inesperada, como sobretensión o sobrecorriente (de lo esperado). "nr_src_pdo" se utiliza para establecer el nivel de Rp cuando el puerto está en la función de origen. También es el tamaño de la matriz de las capacidades de la Fuente local al llenar el búfer que se enviará como los PDO de la Fuente (como en la Negociación de Energía). Si se produce el desbordamiento de uno por uno, es posible que se establezca un nivel de Rp incorrecto y se enviarán PDO de origen incorrectos al puerto asociado. Esto podría causar sobrecorriente o restablecimientos de puertos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc2: host: solucionó el problema de desreferencia en el flujo de finalización de DDMA. Se solucionó el problema de desreferencia variable en el flujo de finalización de DDMA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: core: borrando el búfer circular antes de anularlo. El búfer circular se anula en uart_tty_port_shutdown() bajo el bloqueo de giro. Sin embargo, el PM u otras devoluciones de llamada basadas en temporizadores aún pueden activarse después de este evento sin saber que el puntero del búfer no es válido. Dado que el código de serie es un poco inconsistente al verificar el estado del búfer (algunos se basan en las posiciones de cabecera y cola, otros en el puntero del búfer), es mejor tener ambos alineados, es decir, que el puntero del búfer sea NULL y las posiciones de cabecera y cola sean lo mismo, lo que significa que está vacío. Esto evitará llamadas asincrónicas para desreferenciar el puntero NULL como se informó recientemente en el caso 8250: ERROR: desreferencia del puntero NULL del kernel, dirección: 00000cf5 Cola de trabajo: pm pm_runtime_work EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809). . serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) __start_tx (drivers/tty/serial/8250/8250_port.c:1551) serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654) serial_port_runtime_suspend ( incluir/linux/serial_core.h:667 controladores/tty/serial/serial_port.c:63) __rpm_callback (drivers/base/power/runtime.c:393)? serial_port_remove (drivers/tty/serial/serial_port.c:50) rpm_suspend (drivers/base/power/runtime.c:447) El cambio propuesto evitará que se llame a ->start_tx() durante la suspensión al cerrar el puerto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: serial/pmac_zilog: eliminar la mitigación defectuosa para rx irq Flood La mitigación tenía como objetivo detener irq por completo. Esto puede ser mejor que un bloqueo duro, pero resulta que de todos modos se bloquea si estás usando pmac_zilog como consola serie: ttyPZ0: pmz: rx irq Flood ! ERROR: recursión de spinlock en CPU#0, swapper/0 Esto se debe a que la llamada pr_err() en pmz_receive_chars() da como resultado que pmz_console_write() intente bloquear un spinlock ya bloqueado en pmz_interrupt(). Con CONFIG_DEBUG_SPINLOCK=y, esto produce un error fatal. El spinlock en cuestión es el de la estructura uart_port. Incluso cuando no es fatal, la función de recepción del puerto serie deja de funcionar. Además, el límite de iteración no funciona bien con QEMU, como se puede ver en el informe de error vinculado a continuación. Una búsqueda en la web de otros informes del mensaje de error "pmz: rx irq Flood" no produjo nada. Así que no creo que este código ya sea necesario. Retírelo.

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: Speakup: Evitar crash en palabras muy largas En caso de que una consola esté configurada muy grande y contenga una palabra muy larga (>256 caracteres), tenemos que detenernos antes de la longitud de la palabra. búfer de palabras.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_ncm: corrige el objeto UAF ncm al volver a vincularlo después del error de transporte usb ep Cuando la función ncm está funcionando y luego detiene la interfaz usb0 para desconectar el enlace, se llama a eth_stop() . En este punto, accidentalmente, si ocurre un error de transporte USB en usb_ep_enable(), es posible que 'in_ep' y/o 'out_ep' no estén habilitados. Después de eso, se llama a ncm_disable() para deshabilitar ncm unbind, pero nunca se llama a gether_disconnect() ya que 'in_ep' no está habilitado. Como resultado, el objeto ncm se libera en ncm unbind pero 'dev->port_usb' asociado a 'ncm->port' no es NULL. Y cuando ncm se vincula nuevamente para recuperar netdev, el objeto ncm se reasigna pero la interfaz usb0 ya está asociada al objeto ncm lanzado anteriormente. Por lo tanto, una vez que la interfaz usb0 está activa y se llama a eth_start_xmit(), el objeto ncm liberado se desreferencia y podría causar memoria de use-after-free. [función de desvinculación a través de configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> el error ocurre en usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() ya que ncm->port.in_ep->enabled es falso. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- ncm liberado [enlace de función a través de configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: cm enlazar ncm=ffffff9ac4f8a000 NCM: ncm_set_alt : ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- ncm usb0 lanzado anteriormente: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() No se puede manejar el kernel solicitud de paginación en la dirección virtual dead00000000014f Este parche soluciona el problema verificando si 'ncm->netdev' no es NULL en ncm_disable() para llamar a gether_disconnect() para desasociar 'dev->port_usb'. Es más razonable marcar 'ncm->netdev' para llamar a gether_connect/disconnect en lugar de marcar 'ncm->port.in_ep->enabled' ya que es posible que no esté habilitado pero que se pueda establecer la conexión conjunta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/xe: corrija la fuga de bo en intel_fb_bo_framebuffer_init. Agregue un bo sin referencia en la ruta del error, para evitar que se filtre una referencia de bo. Devuelve 0 en caso de éxito para aclarar la ruta del éxito. (cereza escogida del compromiso a2f3d731be3893e730417ae3190760fcaffdf549)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: corrige la pérdida de memoria en el error create_process. Corrige la pérdida de memoria debido a una referencia mmget filtrada en una ruta de código de manejo de errores que se activa al intentar crear procesos KFD mientras se reinicia la GPU. Está en proceso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/memory-failure: corrige el interbloqueo cuando Hugetlb_optimize_vmemmap está habilitado Cuando hice una prueba dura sin conexión con páginas de Hugetlb, se produce el siguiente interbloqueo: ============ ========================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.8 .0-11409-gf6cef5f8c37f #1 No contaminado ---------------------------------------- -------------- bash/46904 está intentando adquirir el bloqueo: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, en: static_key_slow_dec+0x16/0x60 pero la tarea está ya mantiene el bloqueo: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, en: zone_pcp_disable+0x16/0x40 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/ 0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 Bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 t_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge _página+0x211/0x260 __página_handle_poison+0x45/ 0xc0 error_de_memoria+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entrada_SYSCALL_6 4_after_hwframe+0x6d/0x75 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- bloqueo(pcp_batch_high_lock); bloquear(cpu_hotplug_lock); bloquear(pcp_batch_high_lock); rlock(cpu_hotplug_lock); *** DEADLOCK *** 5 bloqueos retenidos por bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, en: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of ->mutex){+.+.}-{3:3}, en: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, en : kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, en: Memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3: 3}, en: zone_pcp_disable+0x16/0x40 seguimiento de pila: CPU: 10 PID: 46904 Comm: bash Kdump: cargado No contaminado 6.8.0-11409-gf6cef5f8c37f #1 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus _read_lock+0x2a /0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 Memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0 xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca /0x1e0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Código: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 : 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007ffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00 En resumen, La siguiente escena rompe el ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: init/main.c: soluciona un posible desbordamiento de memoria de static_command_line Asignamos memoria de tamaño 'xlen + strlen(boot_command_line) + 1' para static_command_line, pero las cadenas copiadas en static_command_line son extra_command_line y command_line, en lugar de extra_command_line y boot_command_line. Cuando strlen(command_line) > strlen(boot_command_line), static_command_line se desbordará. Este parche simplemente recupera strlen(command_line) que no se consolidó con strlen(boot_command_line) en el commit f5c7310ac73e ("init/main: agregue comprobaciones para el valor de retorno de memblock_alloc*()")