Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu/kvfree: Se corrigió la ejecución de datos en __mod_timer / kvfree_call_rcu KCSAN informa una ejecución de datos al acceder a la variable krcp->monitor_work.timer.expires en la función Schedule_delayed_monitor_work(): BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1: schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline] kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839 trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441 bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203 generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849 bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143 __sys_bpf+0x2e5/0x7a0 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline] __se_sys_bpf kernel/bpf/syscall.c:5739 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739 x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0: __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173 add_timer_global+0x51/0x70 kernel/time/timer.c:1330 __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523 queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552 queue_delayed_work include/linux/workqueue.h:677 [inline] schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline] kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310 worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391 kthread+0x1d1/0x210 kernel/kthread.c:389 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events_unbound kfree_rcu_monitor kfree_rcu_monitor() rearma el trabajo si se produce un "krcp" todavía tiene que estar descargado y esto se hace sin mantener krcp->lock, mientras que kvfree_call_rcu() lo mantiene. Solucionarlo adquiriendo el "krcp->lock" para kfree_rcu_monitor() para que ambas funciones ya no funcionen.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qat/qat_4xxx - arreglado por uno en uof_get_name() La matriz fw_objs[] tiene elementos "num_objs", por lo que > debe ser >= para evitar un límite leer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: qat/qat_420xx - arreglado por uno en uof_get_name() Esto se llama desde uof_get_name_420xx() donde "num_objs" es ARRAY_SIZE() de fw_objs[]. El > debe ser >= para evitar un acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: geni-se: corrige el desbordamiento de la matriz en geni_se_clk_tbl_get() Se supone que este bucle se rompe si la frecuencia devuelta por clk_round_rate() es la misma que en la iteración anterior. Sin embargo, esa verificación no tiene sentido en la primera iteración del ciclo. Conduce a la lectura antes del inicio de la matriz These->clk_perf_tbl[].

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: EDAC/bluefield: corrige un posible desbordamiento de enteros. El argumento de 64 bits para la llamada SMC "obtener información DIMM" consta de mem_ctrl_idx desplazado a la izquierda 16 bits y con operación OR con índice DIMM. Con mem_ctrl_idx definido como 32 bits de ancho, la operación de desplazamiento a la izquierda trunca los 16 bits superiores de información durante el cálculo del argumento SMC. La variable de pila mem_ctrl_idx debe definirse como de 64 bits de ancho para evitar cualquier posible desbordamiento de enteros, es decir, pérdida de datos de los 16 bits superiores.

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