Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: mediatek: clk-mt6765: Agregar verificación para mtk_alloc_clk_data. Agregue la verificación para el valor de retorno de mtk_alloc_clk_data() para evitar la desreferencia al puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: llcc: Manejar un segundo dispositivo sin corrupción de datos. Generalmente solo hay un dispositivo llcc. Pero si hubiera un segundo, incluso una llamada de sonda fallida modificaría el puntero global drv_data. Así que verifique si drv_data es válido antes de sobrescribirlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: corrige la condición de ejecución en la línea de estado, cambia en conexiones inactivas gsm_cleanup_mux() limpia el gsm cerrando todos los DLCI, deteniendo todos los temporizadores, eliminando los dispositivos tty virtuales y limpiando el colas de datos. Sin embargo, este procedimiento puede provocar cambios posteriores en las líneas de estado del módem virtual de un DLCI. Se agregan más datos a la cola de datos salientes y el temporizador de eliminación eliminado se reinicia para manejar esto. En este punto, el procedimiento de limpieza ya ha eliminado muchos recursos. Por tanto, se produce un pánico en el núcleo. Solucione este problema demostrando en gsm_modem_update() que el procedimiento de limpieza no se ha iniciado y que el mux sigue activo. Tenga en cuenta que la escritura en un tty virtual ya está protegida mediante comprobaciones del estado de conexión específico de DLCI.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/mem: arreglo del orden de apagado. Ira informa que la eliminación de cxl_mock_mem causa un bloqueo con el siguiente rastro: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000044 [..] RIP: 0010: cxl_region_decode_reset+0x7f/0x180 [cxl_core] [..] Seguimiento de llamadas: cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x29/0x40 [cxl_core] 0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 dispositivo_del+0x155/0x3e0 device_unregister+0x13/0x60 devm_release_action+0x4d/0x90 ? __pfx_unregister_port+0x10/0x10 [cxl_core] delete_endpoint+0x121/0x130 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 dispositivo_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x15 0 dispositivo_del+0x155/0x3e0? lock_release+0x142/0x290 cdev_device_del+0x15/0x50 cxl_memdev_unregister+0x54/0x70 [cxl_core] Este bloqueo se debe a que se borró el contexto del controlador de cxl_memdev (@cxlds) antes de que el subsistema termine con él. En última instancia, esto se debe a que las regiones de las que este memdev es miembro están siendo derribadas y esperan poder eliminar la referencia a @cxlds, como aquí: static int cxl_region_decode_reset(struct cxl_region *cxlr, int count) .. si (cxlds->rcd) pasa a endpoint_reset; ... Solucionelo manteniendo válido el contexto del controlador hasta que se cancele el registro del dispositivo memdev y, posteriormente, toda la pila de dependencias relacionadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: hantro: compruebe si la operación de reinicio está definida antes de su uso. El i.MX8MM/N/P no define la operación .reset ya que genpd realiza el reinicio de la VPU. Compruebe si la operación .reset está definida antes de llamarla para evitar la desreferencia del puntero NULL. Tenga en cuenta que la etiqueta Fixes está configurada en la confirmación que eliminó la operación de reinicio de la implementación de i.MX8M Hantro G2, esto se debe a que antes de esta confirmación todas las implementaciones definían la operación .reset.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: IB/mlx5: corrige el manejo de errores de la etapa inicial para evitar la doble liberación del mismo QP y UAF. En el improbable caso de que la asignación de la cola de trabajo falle y devuelva NULL en mlx5_mkey_cache_init(), elimine la llamada a mlx5r_umr_resource_cleanup() (que libera el QP) en mlx5_ib_stage_post_ib_reg_umr_init(). Esto evitará intentos de double free del mismo QP cuando __mlx5_ib_add() realice su limpieza. Resuelve un problema: Syzkaller informó un UAF en ib_destroy_qp_user workqueue: No se pudo crear un kthread de rescate para wq "mkey_cache": -EINTR infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642): no se pudo crear la cola de trabajo infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_ inicio: 4075: (pid 1642): el inicio de caché de mr falló -12 ========================================= =========================== BUG: KASAN: uso de losa después de la liberación en ib_destroy_qp_user (drivers/infiniband/core/verbs.c :2073) Lectura de tamaño 8 en la dirección ffff88810da310a8 mediante la tarea repro_upstream/1642 Rastreo de llamadas: kasan_report (mm/kasan/report.c:590) ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073) mlx5r_umr_resource_cleanup (drivers /infiniband/hw/mlx5/umr.c:198) __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4178) mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402) ... Asignado por la tarea 1642: __kmalloc (./include/linux/kasan.h:198 mm/slab_common.c:1026 mm/slab_common.c:1039) create_qp (./include/linux/slab.h:603 ./ include/linux/slab.h:720 ./include/rdma/ib_verbs.h:2795 drivers/infiniband/core/verbs.c:1209) ib_create_qp_kernel (drivers/infiniband/core/verbs.c:1347) mlx5r_umr_resource_init (drivers/ infiniband/hw/mlx5/umr.c:164) mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4070) __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168) mlx5r_probe (drivers/infiniband/ hw/mlx5/main.c:4402) ... Liberado por la tarea 1642: __kmem_cache_free (mm/slub.c:1826 mm/slub.c:3809 mm/slub.c:3822) ib_destroy_qp_user (drivers/infiniband/core/ verbs.c:2112) mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198) mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4076 drivers/infiniband/hw/mlx5/main.c:4065 ) __mlx5_ib_add (controladores/infiniband/hw/mlx5/main.c:4168) mlx5r_probe (controladores/infiniband/hw/mlx5/main.c:4402) ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: compress: corrección para evitar el use after free en dic. Rastreo de llamadas: __memcpy+0x128/0x250 f2fs_read_multi_pages+0x940/0xf7c f2fs_mpage_readpages+0x5a8/0x624 f2fs_readahead+0x5c/0x110 page_cache_ra_ ilimitado +0x1b8/0x590 do_sync_mmap_readahead+0x1dc/0x2e4 filemap_fault+0x254/0xa8c f2fs_filemap_fault+0x2c/0x104 __do_fault+0x7c/0x238 do_handle_mm_fault+0x11bc/0x2d14 do_mem_abort+0x3a8 /0x1004 el0_da+0x3c/0xa0 el0t_64_sync_handler+0xc4/0xec el0t_64_sync+0x1b4/0x1b8 En f2fs_read_multi_pages(), una vez que se llamó a f2fs_decompress_cluster() si llegamos a la página almacenada en caché en el caché de compress_inode, es posible que se libere dic, es necesario romper el ciclo en lugar de continuarlo, para evitar acceder a un puntero dic no válido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hid: cp2112: corrige la inicialización duplicada de la cola de trabajo. Anteriormente, el controlador cp2112 llamaba INIT_DELAYED_WORK dentro de cp2112_gpio_irq_startup, lo que generaba inicializaciones duplicadas de la cola de trabajo en inicios IRQ posteriores después de una solicitud inicial. Esto resultó en una advertencia en set_work_data en workqueue.c, así como en una rara desreferencia NULL dentro de process_one_work en workqueue.c. En su lugar, inicialice la cola de trabajo dentro de _probe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: corrige el manejo de refcnt en padata_free_shell(). En un entorno arm64 de alta carga, la prueba pcrypt_aead01 en LTP puede provocar problemas de UAF (Use-After-Free) del sistema. Debido al extenso análisis de la llamada a la función pcrypt_aead01, describiré el escenario del problema usando un modelo simplificado: supongamos que hay un usuario de padata llamado `user_function` que cumple con el requisito de padata de llamar a `padata_free_shell` después de `serial()`. ha sido invocado, como se demuestra en el siguiente código: ```c struct request { struct padata_priv padata; finalización de la estructura *hecho; }; void paralelo(struct padata_priv *padata) { hacer_algo(); } void serial(struct padata_priv *padata) { solicitud de estructura *request = container_of(padata, solicitud de estructura, padata); completar(solicitud->hecho); } void user_function() { DECLARE_COMPLETION(hecho) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&hecho); padata_free_shell(); } ``` En el archivo padata.c correspondiente, hay el siguiente código: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Debido a la alta carga del sistema y la acumulación de software no ejecutado en este momento, `local_bh_enable()` en padata tarda más de lo habitual en ejecutarse. Posteriormente, al acceder a `pd->refcnt`, `pd` ya ha sido liberado por `padata_free_shell()`, lo que genera un problema de UAF con `pd->refcnt`. La solución es sencilla: agregue `refcount_dec_and_test` antes de llamar a `padata_free_pd` en `padata_free_shell`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc2: corrige posible desreferencia de puntero NULL causada por concurrencia de controladores. En _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" se ejecuta sin mantener presionado el bloqueo "hsotg->lock" . En _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv es NULL ##\n"); salir; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Usa urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); Cuando _dwc2_hcd_urb_enqueue() y _dwc2_hcd_urb_dequeue() se ejecutan simultáneamente, la verificación NULL de "urb->hcpriv" se puede ejecutar antes de "urb->hcpriv = NULL". Después de que urb->hcpriv sea NULL, se puede usar en la llamada de función a dwc2_hcd_urb_dequeue(), lo que puede provocar una desreferencia del puntero NULL. Este posible error se encuentra mediante una herramienta experimental de análisis estático desarrollada por mí. Esta herramienta analiza las API de bloqueo para extraer pares de funciones que se pueden ejecutar simultáneamente y luego analiza las instrucciones en las funciones emparejadas para identificar posibles errores de concurrencia, incluidas ejecucións de datos y violaciones de atomicidad. El posible error anterior se informa cuando mi herramienta analiza el código fuente de Linux 6.5. Para corregir este posible error, se debe ejecutar "urb->hcpriv = NULL" manteniendo presionado el bloqueo "hsotg->lock". Después de usar este parche, mi herramienta nunca informa el posible error, con la configuración del kernel allyesconfig para x86_64. Como no tengo hardware asociado, no puedo probar el parche en tiempo de ejecución y simplemente verificarlo de acuerdo con la lógica del código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/bridge: lt8912b: soluciona el fallo al desconectar el puente. El controlador lt8912b, en su función de desconectar el puente, llama a drm_connector_unregister() y drm_connector_cleanup(). drm_connector_unregister() debe llamarse solo para conectores registrados explícitamente con drm_connector_register(), lo cual no es el caso en lt8912b. El gancho drm_connector_funcs.destroy del controlador está configurado en drm_connector_cleanup(). Por lo tanto, el controlador no debe llamar ni a drm_connector_unregister() ni a drm_connector_cleanup() en su lt8912_bridge_detach(), ya que causan un bloqueo al desconectar el puente: No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 00000000000000000 Información de cancelación de memoria: ESR = 0x0000000096000006 EC = 0x25 : DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: fallo de traducción de nivel 2 Información de cancelación de datos: ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 tabla de páginas de usuario: páginas de 4k, VA de 48 bits, pgdp=00000000858f3000 [0000000000000000000000000859180] 03, p4d =0800000085918003, pud=0800000085431003, pmd=0000000000000000 Error interno: Ups: 0000000096000006 [#1] Módulos SMP PREEMPT vinculados en: tidss(-) display_connector lontium_lt8912b tc35876 8 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks CPU: 3 PID: 462 Comunicaciones: rmmod Contaminado: GW 6.5.0-rc2+ #2 Nombre del hardware: Toradex Verdin AM62 en la placa de desarrollo Verdin (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: drm_connector_cleanup+0x78/0x2d4 [ drm] lr: lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b] sp: ffff800082ed3a90 x29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000 x26: 00000000000 x25: dead000000000122 x24: dead000000000122 x23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000 x20: 00000000000000000 x 19: ffff000003fb6260 x18: fffffffffffe56e8 x17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038 x14: 00000000000000000 x13: ffff800081914b48 x12: 0000000040e x11: 000000000000015a x10: ffff80008196ebb8 x9: ffff800081914b48 x8: 00000000fffffff x7: ffff0000040c1940 x6: ffff80007aa649d0 0000000000000000 x4: 0000000000000001 x3: ffff80008159e008 x2: 0000000000000000 x1 : 0000000000000000 x0 : 00000000000000000 Rastreo de llamadas: drm_connector_cleanup+0x78/0x2d4 [drm] lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b] drm_bridge_detach+0x44/0x84 [drm_encoder] _cleanup+0x40/0xb8 [drm] drmm_encoder_alloc_release+0x1c/0x30 [drm] drm_managed_release+ 0xac/0x148 [drm] drm_dev_put.part.0+0x88/0xb8 [drm] devm_drm_dev_init_release+0x14/0x24 [drm] devm_action_release+0x14/0x20 release_nodes+0x5c/0x90 devres_release_all+0x8c/0xe0 device_unbind_cleanup +0x18/0x68 device_release_driver_internal+0x208/ 0x23c driver_detach+0x4c/0x94 bus_remove_driver+0x70/0xf4 driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 tidss_platform_driver_exit+0x18/0xb2c [tidss] __arm64_sys_delete_module+0x1a0/0 x2b4 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x60/0x10c do_el0_svc_compat+ 0x1c/0x40 el0_svc_compat+0x40/0xac el0t_32_sync_handler+0xb0/0x138 el0t_32_sync+0x194/0x198 Código: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: mediatek: clk-mt7629: Agregar verificación para mtk_alloc_clk_data. Agregue la verificación para el valor de retorno de mtk_alloc_clk_data() para evitar la desreferencia al puntero NULL.