Vulnerabilidades

El desbordamiento de búfer de almacenamiento dinámico en ANGLE en Google Chrome anterior a 123.0.6312.122 permitía a un atacante remoto explotar potencialmente la corrupción del montón a través de una página HTML manipulada. (Severidad de seguridad de Chrome: alta)

Vulnerabilidad de Cross-Site Request Forgery (CSRF) en Hidekazu Ishikawa X-T9, Hidekazu Ishikawa Lightning, themeinwp Default Mag, Out the Box Namaha, Out the Box CityLogic, Marsian i-max, Jetmonsters Emmet Lite, Macho Themes Decode, Wayneconnor Sliding Door, Out the Box Shopstar!, Modernthemesnet Gridsby, TT Themes HappenStance, Marsian i-excel, Out the Box Panoramic, Modernthemesnet Sensible WP. Este problema afecta a X-T9: desde n/d hasta 1.19.0; Lightning: desde n/d hasta 15.18.0; Default Mag: desde n/d hasta 1.3.5; Namaha: desde n/d hasta 1.0.40; CityLogic: desde n/d hasta 1.1.29; i-max: desde n/d hasta 1.6.2; Emmet Lite: desde n/d hasta 1.7.5; Decode: desde n/d hasta 3.15.3; Sliding Door: desde n/d hasta 3.3; Shopstar!: desde n/d hasta 1.1.33; Gridsby: desde n/d hasta 1.3.0; HappenStance: desde n/d hasta 3.0.1; i-excel: desde n/d hasta 1.7.9; Panoramic: desde n/d hasta 1.1.56; Sensible WP: desde n/d hasta 1.3.1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: CT, corrige asignaciones múltiples y fuga de memoria de actos mod La descarga de la acción CT clear agrega acciones mod hdr adicionales a las acciones mod originales del flujo para borrar los registros que contienen ct_state. Cuando dicho flujo también incluye la acción encap, un evento de actualización vecinal puede hacer que el controlador descargue el flujo y luego lo vuelva a descargar. Cada vez que esto sucede, el manejo de ct clear agrega ese mismo conjunto de acciones mod hdr para restablecer ct_state hasta que se alcanza el máximo de acciones mod hdr. Además, el controlador nunca libera las acciones mod hdr asignadas y causa una fuga de memoria. Corrija los dos problemas anteriores moviendo la asignación de actos mod de CT clear a la fase de acciones de análisis y solo úselo al descargar la regla. La liberación de actos mod se realizará en el flow_put() normal. seguimiento inverso: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_actualización_flujos+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_actualización+0x39a/0x5d0 [mlx5_core]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/prime: Arreglar el use-after-free en mmap con drm_gem_ttm_mmap drm_gem_ttm_mmap() elimina una referencia al objeto gema en caso de éxito. Si el refcount del objeto gema == 1 en la entrada a drm_gem_prime_mmap(), esa eliminación liberará el objeto gema y el drm_gem_object_get() posterior será un UAF. Se soluciona tomando una referencia antes de llamar al ayudante mmap. Este problema se previó cuando se agregó la eliminación de referencia en el commit 9786b65bc61ac ("drm/ttm: corregir el recuento de referencias mmap"): "Para que eso funcione correctamente, la llamada drm_gem_object_get() en drm_gem_ttm_mmap() debe moverse para que suceda antes de llamar a obj->funcs->mmap(), de lo contrario, el recuento de referencias de la gema bajaría a cero".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: libera q_vectors antes de las colas en iavf_disable_vf iavf_free_queues() borra adaptador->num_active_queues, del que depende iavf_free_q_vectors(), por lo que se debe intercambiar el orden de estas dos llamadas de función en iavf_disable_vf(). Esto resuelve un pánico que se produce cuando se deshabilita la interfaz y luego se vuelve a activar después de que se restablece la comunicación PF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal: Fix NULL pointer dereferences in of_thermal_ functions of_parse_thermal_zones() analiza el nodo thermal-zones y registra un dispositivo thermal_zone para cada subnodo. Sin embargo, si una zona térmica está consumiendo un sensor térmico y ese dispositivo de sensor térmico aún no ha realizado la prueba, un intento de establecer trip_point_*_temp para ese dispositivo de zona térmica puede provocar una desreferencia de puntero NULL. Arréglelo. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000020 ... Seguimiento de llamadas: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 Mientras tanto, corrija también la posible desreferencia del puntero NULL en otras funciones: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se corrige la corrupción de list_add() en lpfc_drain_txq() Al analizar la lista txq en lpfc_drain_txq(), el controlador intenta pasar las solicitudes al adaptador. Si dicho intento falla, se establece una cadena "fail_msg" local y se genera un mensaje de registro. Luego, el trabajo se agrega a una lista de finalizaciones para su cancelación. El procesamiento de cualquier otro trabajo de la lista txq continúa, pero como "fail_msg" permanece establecido, los trabajos se agregan a la lista de finalizaciones independientemente de si se pasó un wqe al adaptador. Si se agrega correctamente a txcmplq, los trabajos se agregan a ambas listas, lo que da como resultado la corrupción de la lista. Se soluciona borrando la cadena fail_msg después de agregar un trabajo a la lista de finalizaciones. Esto evita que los trabajos posteriores se agreguen a la lista de finalizaciones a menos que hayan tenido una falla apropiada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dpaa2-eth: se ha corregido el error use-after-free en dpaa2_eth_remove. El acceso a netdev después de free_netdev() provocará un error use-after-free. Mueva el registro de depuración antes de la llamada free_netdev() para evitarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: sunxi-ng: Anular el registro de relojes/reinicios al desvincular Actualmente, desvincular un controlador CCU anula la asignación de la región MMIO del dispositivo, mientras que deja sus relojes/reinicios y sus proveedores registrados. Esto puede causar una falla de página más adelante cuando alguna operación de reloj intenta realizar MMIO. Solucione esto separando la inicialización de CCU de la asignación de memoria y luego usando una devolución de llamada devres para anular el registro de los relojes y reinicios. Esto también corrige una pérdida de memoria de `struct ccu_reset` y usa el propietario correcto (el controlador de plataforma específico) para los relojes y reinicios. Los primeros proveedores de reloj OF nunca se anulan del registro y es posible un manejo de errores limitado, por lo que en su mayoría no se modifican. El informe de errores se hace más consistente moviendo el mensaje dentro de of_sunxi_ccu_probe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: host: ohci-tmio: verificar el valor de retorno después de llamar a platform_get_resource() Causará null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el valor de retorno.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: gus: corrige la desreferencia de puntero nulo en el bloque de puntero El bloque de puntero devuelto por snd_gf1_dma_next_block podría ser nulo, por lo que existe un posible problema de desreferencia de puntero nulo. Solucione esto agregando una verificación nula antes de la desreferencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/fair: Evitar que los grupos de tareas inactivos recuperen cfs_rq Kevin informa fallos que apuntan a un use-after-free de un cfs_rq en update_blocked_averages(). La depuración inicial reveló que tenemos cfs_rq activos (on_list=1) en un grupo de tareas a punto de ser kfree() en free_fair_sched_group(). Sin embargo, no estaba claro cómo puede suceder eso. Su configuración del kernel resultó en un diseño de struct sched_entity que coloca el miembro 'my_q' directamente en el medio del objeto, lo que hace que se superponga incidentalmente con el puntero de lista libre de SLUB. Eso, en combinación con la manipulación del puntero de lista libre de SLAB_FREELIST_HARDENED, conduce a una violación de acceso confiable en forma de un #GP que hizo que el UAF fallara rápidamente. Michal parece haberse topado con el mismo problema[1]. Él ya diagnosticó correctamente que el commit a7b359fc6a37 ("sched/fair: Insertar correctamente cfs_rq en la lista al desregular") está causando que se cumplan las condiciones previas para que se produzca la UAF al volver a agregar cfs_rq también a los grupos de tareas que ya no tienen tareas en ejecución, es decir, también a los que están inactivos. Sin embargo, su análisis no detecta la causa raíz real y no se puede ver solo desde el backtrace del bloqueo, ya que el verdadero infractor es tg_unthrottle_up() que se llama a través de sched_cfs_period_timer() mediante la interrupción del temporizador en un momento inconveniente. Cuando unregister_fair_sched_group() desvincula todos los cfs_rq del grupo de tareas que está inactivo, no se protege a sí mismo de ser interrumpido. Si la interrupción del temporizador se activa mientras iteramos sobre todas las CPU o después de que unregister_fair_sched_group() haya terminado pero antes de desvincular el grupo de tareas, sched_cfs_period_timer() se ejecutará y recorrerá la lista de grupos de tareas, intentando liberar cfs_rq, es decir, volver a agregarlos al grupo de tareas moribundo. Estos serán posteriormente -- en free_fair_sched_group() -- kfree()'ed mientras siguen vinculados, lo que lleva a los fuegos artificiales que Kevin y Michal están viendo. Para solucionar esta ejecución, asegúrese de que el grupo de tareas moribundo se desvincule primero. Sin embargo, simplemente cambiar el orden de anulación del registro y desvinculación del grupo de tareas no es suficiente, ya que los caminantes de RCU concurrentes aún podrían verlo, como se puede ver a continuación: CPU1: CPU2: : timer IRQ: : do_sched_cfs_period_timer(): : : : distributed_cfs_runtime(): : rcu_read_lock(); : : : unthrottle_cfs_rq(): sched_offline_group(): : : walk_tg_tree_from(…,tg_unthrottle_up,…): list_del_rcu(&tg->list); : (1) : list_for_each_entry_rcu(child, &parent->children, brothers) : : (2) list_del_rcu(&tg->siblings); : : tg_unthrottle_up(): anular_registro_justo_sched_group(): struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)]; : : list_del_leaf_cfs_rq(tg->cfs_rq[cpu]); : : : : si (!cfs_rq_está_decaído(cfs_rq) || cfs_rq->nr_en_ejecución) (3) : lista_agregar_hoja_cfs_rq(cfs_rq); : : : : : : : : : ---truncado---