Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: hisi: corrige el use after free cuando falla el registro de pmu. Cuando no logramos registrar el pmu sin núcleo, es posible que no se haya asignado el contexto de pmu. El manejo del error llamará a cpuhp_state_remove_instance() para llamar a la devolución de llamada fuera de línea de uncore pmu, que migra el contexto de pmu. Dado que eso puede conducir a algún tipo de use after free. Utilice cpuhp_state_remove_instance_nocalls() en lugar de cpuhp_state_remove_instance() para que los notificadores no se ejecuten después de que el dispositivo PMU no haya podido registrarse.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/mediatek: soluciona el problema de cobertura con desbordamiento de enteros involuntario 1. En lugar de multiplicar 2 variables de diferentes tipos. Cambie para asignar un valor a una variable y luego multiplique la otra variable. 2. Agregue una variable int para el cálculo del multiplicador en lugar de calcular diferentes tipos de multiplicadores con la variable dma_addr_t directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: rescate anticipado si el área AUX de la solicitud está fuera de los límites. Cuando perf-record con un área AUX grande, por ejemplo, 4 GB, falla con: #perf record -C 0 -m, 4G -e arm_spe_0// -- el sueño 1 no pudo mapear con 12 (no se puede asignar memoria) y revela una ADVERTENCIA con __alloc_pages(): ------------[ cortar aquí ] ------------ ADVERTENCIA: CPU: 44 PID: 17573 en mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Rastreo de llamadas: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/ 0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' asignado por kcalloc() es una matriz de punteros que se utiliza para mantener páginas de seguimiento AUX. La página asignada para esta matriz es físicamente contigua (y virtualmente contigua) con un orden de 0..MAX_ORDER. Si el tamaño de la matriz de punteros cruza la limitación establecida por MAX_ORDER, se revela una ADVERTENCIA. Por lo tanto, salve pronto con -ENOMEM si el área AUX de la solicitud está fuera de los límites, por ejemplo: #perf record -C 0 -m ,4G -e arm_spe_0// -- el sueño 1 no pudo asignar mm con 12 (no se puede asignar memoria)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lock/ww_mutex/test: soluciona una posible corrupción de la cola de trabajo. En algunos casos, al ejecutar el código test-ww_mutex, veía un comportamiento extraño en el que a veces parecía que flush_workqueue regresaba antes que todos los subprocesos de trabajo. hemos terminado. A menudo, esto causaría fallas extrañas ya que los mutex se liberarían mientras se estaban usando. Al observar el código, hay un problema de duración, ya que el subproceso de control que genera el trabajo asigna las estructuras de "estrés de estructura" que se pasan a los subprocesos de la cola de trabajo. Luego, cuando los subprocesos de la cola de trabajo finalizan, liberan la estructura de tensión que se les pasó. Desafortunadamente, el nodo work_struct de la cola de trabajo está en la estructura de estrés. Lo que significa que work_struct se libera antes de que regrese el hilo de trabajo y mientras descarga_workqueue está esperando. Parece una mejor idea que el subproceso de control asigne y libere las estructuras de tensión, de modo que podamos estar seguros de no corromper la cola de trabajo al liberar la estructura prematuramente. Entonces, este parche reelabora la prueba para hacerlo, y con este cambio ya no veo los primeros retornos de Flush_workqueue.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nbd: corrija uaf en nbd_open Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk y blk_cleanup_disk") limpia el disco mediante blk_cleanup_disk() y no configurará disk->private_data como NULL como antes. UAF puede activarse en nbd_open() si alguien intenta abrir el dispositivo nbd justo después de nbd_put() ya que nbd ha estado libre en nbd_dev_remove(). Solucione este problema implementando ->free_disk y datos privados gratuitos en él.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fbdev: imsttfb: corrige una fuga de recursos en la sonda. He reescrito el manejo de errores, pero el error es que si init_imstt() falla, debemos llamar a iounmap(par-> cmap_regs).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: no transmitir a otras CPU al iniciar un contador. Este comando: $ perf record -e ciclos:k -e instrucciones:k -c 10000 -m 64M dd if =/dev/zero of=/dev/null count=1000 da lugar a esta advertencia del kernel: [444.364395] ADVERTENCIA: CPU: 0 PID: 104 en kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [444.364515] Módulos vinculados en: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec No contaminado 6.6.0-rc6-00051-g391df82e8ec3-dirty #73 [ 444.364771] Nombre de hardware: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [444.364998] s1: ff60000002c54d98 a0: ff60000002a73940 a1: 0000000000000000 [444.365013] a2: 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029 ] a5 : 000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2: 0000000000000000 s3: ffffffffffffffff s4: ff60000002c54d98 [ 444.365060] s5: ffffffff81539610 s6: ffffffff80c20c48 s7: 0000000000000000 [444.365075] s8: 0000000000000000 s9: 0000000000000001 s10: 0000000000000001 [444.365090] s11: ffffffff80099394 t3: 0000000000000003 t4: 00000000eac0c6e6 [444.365104] t5: 0000000400000000 t6: ff60000002e010d0 [444.365120] estado: 0000000200000100 badaddr: 0000000000000000 causa: 0000000000000003 [444.365226] [] smp_call_function_many_cond+0x42c/0x436 [444.365295] [] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [< ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [] _task_tick+0x78/0x8c [ 444.365368] [] scheduler_tick+0xe6/0x25e [ 444.365383] [] update_process_times+0x80/0x96 [ 444.365398] [] tick_sched_handle+0x26/0x52 [ 444.365410] [] [ 444.365422] [] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [] hrtimer_interrupt+0xce/0x1da [ 444.365444] [] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [] cpu_devid_irq+0x80/0x114 [ 444.365470] [] generic_handle_domain_irq+0x1c/ 0x2a [ 444.365483] [] riscv_intc_irq+0x2e/0x46 [ 444.365497] [] handle_riscv_irq+0x4a/0x74 [ 444.365521 [] do_irq+0x7c/0x7e [ 444.365796] ---[ final de seguimiento 0000000000000000 ]--- Esto se debe a que la solución en la confirmación 3fec323339a4 ("drivers: perf: Fix panic in riscv SBI mmap support") era incorrecta ya que no hay necesidad de transmitir a otras CPU al iniciar un contador, eso solo es necesario en mmap cuando el Es posible que los contadores ya se hayan iniciado en otras CPU, así que simplemente elimine esta transmisión.