Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: glink: fix off-by-one in Connector_status Los índices del conector UCSI comienzan desde 1 hasta 3, PMIC_GLINK_MAX_PORTS. Corrija la condición en la devolución de llamada pmic_glink_ucsi_connector_status(), arreglando el informe de orientación tipo C para el tercer conector USB-C.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: tegra194: Mover las desinfecciones del controlador a pex_ep_event_pex_rst_deassert(). Actualmente, la función de desinfección de endpoints dw_pcie_ep_cleanup() y la función de notificación deinit de EPF pci_epc_deinit_notify() se llaman durante la ejecución de pex_ep_event_pex_rst_assert(), es decir , cuando el anfitrión tiene afirmó PREST#. Pero poco después de este paso, el host también desactivará refclk. Todos los SoC de endpoint tegra194 admitidos a partir de ahora dependen de la refclk del host para mantener el controlador operativo. Debido a esta limitación, cualquier acceso a los registros de hardware en ausencia de refclk resultará en una falla completa del endpoint. Desafortunadamente, la mayoría de las desinfecciones del controlador requieren acceder a los registros de hardware (como la desinfección eDMA realizada en dw_pcie_ep_cleanup(), etc...). Por lo tanto, estas funciones de desinfección pueden provocar el bloqueo del SoC del endpoint una vez que el host afirma el número PREST. Una forma de abordar este problema es generando el refclk en el propio endpoint y sin depender del host. Pero eso no siempre es posible ya que algunos de los diseños de terminales requieren que el terminal consuma refclk del host. Por lo tanto, solucione este bloqueo moviendo las desinfecciones del controlador al inicio de la función pex_ep_event_pex_rst_deassert(). Esta función se llama siempre que el host ha anulado PERST# y se garantiza que refclk estará activo en este punto. Entonces, al inicio de esta función (después de habilitar los recursos), se puede realizar la desinfección del controlador. Una vez finalizado, el resto de la ejecución del código para la desactivación de PERST# puede continuar como de costumbre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: qcom-ep: mover las desinfecciones del controlador a qcom_pcie_perst_deassert() Actualmente, la función de desinfección de endpoints dw_pcie_ep_cleanup() y la función de notificación deinit de EPF pci_epc_deinit_notify() se llaman durante la ejecución de qcom_pcie_perst_assert( ) es decir, cuando el host ha afirmado PREST#. Pero poco después de este paso, el host también desactivará refclk. Todos los SoC de endpoint de Qcom admitidos a partir de ahora dependen de la refclk del host para mantener el controlador operativo. Debido a esta limitación, cualquier acceso a los registros de hardware en ausencia de refclk provocará un fallo completo del terminal. Desafortunadamente, la mayoría de las desinfecciones del controlador requieren acceder a los registros de hardware (como la desinfección de eDMA realizada en dw_pcie_ep_cleanup(), apagar MHI EPF, etc.). Por lo tanto, estas funciones de desinfección actualmente causan el bloqueo en el SoC del endpoint una vez que el host afirma PREST#. Una forma de abordar este problema es generando el refclk en el propio endpoint y sin depender del host. Pero eso no siempre es posible ya que algunos de los diseños de terminales requieren que el terminal consuma refclk del host (como me dijeron los ingenieros de Qcom). Por lo tanto, solucione este bloqueo moviendo las desinfecciones del controlador al inicio de la función qcom_pcie_perst_deassert(). Se llama a qcom_pcie_perst_deassert() cada vez que el host ha desactivado PERST# y se garantiza que refclk estará activo en este punto. Entonces, al inicio de esta función (después de habilitar los recursos), se puede realizar la desinfección del controlador. Una vez finalizado, el resto de la ejecución del código para la desactivación de PERST# puede continuar como de costumbre.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: svcrdma: soluciona un desbordamiento de enteros Dan Carpenter informa: > Commit 78147ca8b4a9 ("svcrdma: agrega una estructura de datos de lista de fragmentos analizados") del 22 de junio de 2020 (linux-next ), conduce a la siguiente > Advertencia del comprobador estático Smatch: > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() > advertencia: tamaño de desbordamiento potencial controlado por el usuario 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c > 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt) > 489 { > 490 u32 segcount; > 491 __be32 *p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 devuelve falso; > 495 > 496 /* Un recuento de segmentos falso provoca que esta comprobación de desbordamiento del búfer falle. */> 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p)); > > > segcount es un u32 que no es de confianza. En sistemas de 32 bits, cualquier cosa >= TAMAÑO_MAX / 16 tendrá > un desbordamiento de enteros y algunos de esos valores serán aceptados por > xdr_inline_decode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: clk-apple-nco: Agregar verificación NULL en applnco_probe Agregar verificación NULL en applnco_probe, para gestionar el error de desreferencia del puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: corrige el valor no inicializado en ocfs2_file_read_iter() Syzbot ha informado el siguiente símbolo KMSAN: ERROR: KMSAN: valor uninicial en ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30 Uninit se creó en: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Dado que una instancia de 'struct kiocb' puede pasarse desde la capa de bloque con el campo 'privado' no inicializado, introduzca 'ocfs2_iocb_init_rw_locked()' y utilícelo desde donde podría tomar 'ocfs2_dio_end_io()' cuidado, es decir en 'ocfs2_file_read_iter()' y 'ocfs2_file_write_iter()'.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath9k: agregue verificación de rango para conn_rsp_epid en htc_connect_service() Encontré el siguiente error en mi fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/ wireless/ath/ath9k/htc_hst.c:26:51 el índice 255 está fuera del rango para el tipo 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0- 1 01/04/2014 Cola de trabajo: eventos request_firmware_work_func Seguimiento de llamadas: dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0... Dado que se ha confirmado que este error es causado por una verificación insuficiente de conn_rsp_epid, creo que sería apropiado agregar una verificación de rango para conn_rsp_epid a htc_connect_service() para evitar que ocurra el error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scpi: Verificar el recuento de OPP de DVFS devuelto por el firmware Corrige un fallo del kernel con el siguiente seguimiento de llamadas cuando el firmware SCPI devuelve un recuento de OPP de cero. dvfs_info.opp_count puede ser cero en algunas plataformas durante la prueba de reinicio, y el kernel se bloqueará después de desreferenciar el puntero a kcalloc(info->count, sizeof(*opp), GFP_KERNEL). | No se puede gestionar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000028 | Información de aborto de memoria: | ESR = 0x96000004 | Clase de excepción = DABT (EL actual), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Información de aborto de datos: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | usuario pgtable: 4k páginas, VAs de 48 bits, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Error interno: Oops: 96000004 [#1] SMP | scpi-hwmon: la sonda de PHYT000D:00 falló con el error -110 | Proceso systemd-udevd (pid: 1701, límite de pila = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd No contaminado 4.19.90+ #1 | Nombre del hardware: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Rastreo de llamadas: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | plataforma_drv_probe+0x58/0xa8 | realmente_probe+0x260/0x3d0 | dispositivo_sonda_controlador+0x12c/0x148 | adjuntar_controlador_dispositivo+0x74/0x98 | __adjuntar_controlador+0xb4/0xe8 | bus_para_cada_dispositivo+0x88/0xe0 | adjuntar_controlador+0x30/0x40 | agregar_controlador_bus+0x178/0x2b0 | registro_controlador+0x64/0x118 | __registro_controlador_plataforma+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | hacer_una_llamada_inicio+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Código: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ fin del seguimiento 06feb22469d89fa8 ]--- | Pánico del kernel: no se sincroniza: Excepción fatal | SMP: deteniendo las CPU secundarias | Desplazamiento del kernel: deshabilitado | Características de la CPU: 0x10,a0002008 | Límite de memoria: ninguno

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ALSA: usb-audio: corrige lecturas fuera de los límites al encontrar fuentes de reloj. El código actual del controlador de audio USB no verifica la bLongitud de cada descriptor al atravesar los descriptores de reloj. Es decir, cuando un dispositivo proporciona un descriptor falso con una longitud b más corta, el controlador podría alcanzar lecturas fuera de los límites. Para solucionarlo, este parche agrega controles de cordura a las funciones de validación para el recorrido del descriptor de reloj. Cuando la longitud del descriptor es más corta de lo esperado, se omite en el bucle. Para los descriptores de fuente de reloj y multiplicador de reloj, podemos comparar bLength con el sizeof() de cada tipo de descriptor. OTOH, el descriptor del selector de reloj de UAC2 y UAC3 tiene una matriz de elementos bNrInPins y dos campos más en su cola, por lo que deben verificarse además de la verificación sizeof().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige el acceso fuera de los límites de las entradas del directorio. En el caso de que el tamaño del directorio sea mayor o igual al tamaño del clúster, si start_clu se convierte en un clúster EOF (un clúster no válido cluster) debido a una corrupción del sistema de archivos, entonces la entrada del directorio donde ei->hint_femp.eidx sugerencia está fuera del directorio, lo que resulta en un acceso fuera de los límites, lo que puede causar una mayor corrupción del sistema de archivos. Este commit agrega una verificación de start_clu; si es un clúster no válido, el archivo o directorio se tratará como vacío.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: um: corrige el posible desbordamiento de enteros durante la configuración de physmem. Este problema ocurre cuando el tamaño real del mapa es mayor que LONG_MAX, lo que se puede activar fácilmente en UML/i386.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: evita un posible desbordamiento de enteros. Si la longitud de la etiqueta es >= U32_MAX - 3, entonces la suma "longitud + 4" puede provocar un desbordamiento de enteros. Solucione este problema dividiendo la decodificación en varios pasos para que decode_cb_compound4res() no tenga que realizar aritmética en el valor de longitud no seguro.