Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Reparar llamada de seguimiento IPsec RoCE MPV Evita que se realice el seguimiento de llamada a continuación al no permitir la creación de IPsec en un esclavo, si el dispositivo maestro no admite IPsec. ADVERTENCIA: CPU: 44 PID: 16136 en kernel/locking/rwsem.c:240 down_read+0x75/0x94 Módulos vinculados en: esp4_offload esp4 act_mirred act_vlan cls_flower sch_ingress mlx5_vdpa vringh vhost_iotlb vdpa mst_pciconf(OE) nfsv3 nfs_acl nfs lockd grace fscache netfs xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill cuse fuse rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_ipoib iw_cm ib_cm ipmi_ssif intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd kvm_amd kvm irqbypass _pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel sha1_ssse3 dell_smbios ib_uverbs aesni_intel crypto_simd dcdbas wmi_bmof dell_wmi_descriptor cryptd pcspkr ib_core acpi_ipmi sp5100_tco ccp i2c_piix4 ipmi_si ptdma k10temp ipmi_devintf ipmi_msghandler acpi_power_meter acpi_cpufreq ext4 mbcache jbd2 sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect mlx5_core sysimgblt fb_sys_fops cec ahci libahci mlxfw drm pci_hyperv_intf libata tg3 sha256_ssse3 tls megaraid_sas i2c_algo_bit psample wmi dm_mirror dm_region_hash dm_log dm_mod [última descarga: mst_pci] CPU: 44 PID: 16136 Comm: kworker/44:3 Kdump: cargado Contaminado: GOE 5.15.0-20240509.el8uek.uek7_u3_update_v6.6_ipsec_bf.x86_64 #2 Nombre del hardware: Dell Inc. PowerEdge R7525/074H08, BIOS 2.0.3 15/01/2021 Cola de trabajo: eventos xfrm_state_gc_task RIP: 0010:down_read+0x75/0x94 Código: 00 48 8b 45 08 65 48 8b 14 25 80 fc 01 00 83 e0 02 48 09 d0 48 83 c8 01 48 89 45 08 5d 31 c0 89 c2 89 c6 89 c7 e9 cb 88 3b 00 <0f> 0b 48 8b 45 08 a8 01 74 b2 a8 02 75 ae 48 89 c2 48 83 ca 02 f0 RSP: 0018:ffffb26387773da8 EFLAGS: 00010282 RAX: 000000000000000 RBX: ffffa08b658af900 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ff886bc5e1366f2f RDI: 0000000000000000 RBP: ffffa08b658af940 R08: 00000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0a9bfb31540 R13: ffffa0a9bfb37900 R14: 000000000000000 R15: ffffa0a9bfb37905 FS: 000000000000000(0000) GS:ffffa0a9bfb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a45ed814e8 CR3: 000000109038a000 CR4: 0000000000350ee0 Seguimiento de llamadas: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_devcom_for_each_peer_begin+0x29/0x60 [mlx5_core] ? down_read+0x75/0x94 ? __warn+0x80/0x113 ? down_read+0x75/0x94 ? report_bug+0xa4/0x11d ? handle_bug+0x35/0x8b ? asm_exc_invalid_op+0x16/0x1b ? lectura_abajo+0x75/0x94 ? lectura_abajo+0xe/0x94 mlx5_devcom_para_cada_par_inicio+0x29/0x60 [núcleo_mlx5] mlx5_ipsec_fs_roce_tx_destroy+0xb1/0x130 [núcleo_mlx5] tx_destroy+0x1b/0xc0 [núcleo_mlx5] tx_ft_put+0x53/0xc0 [núcleo_mlx5] mlx5e_xfrm_estado_libre+0x45/0x90 [núcleo_mlx5] ___xfrm_estado_destruir+0x10f/0x1a2 xfrm_estado_gc_task+0x81/0xa9 proceso_uno_trabajo+0x1f1/0x3c6 subproceso_trabajador+0x53/0x3e4 ? proceso_uno_trabajo.frío+0x46/0x3c kthread+0x127/0x144 ? conjunto_kthread_struct+0x60/0x52 ret_from_fork+0x22/0x2d ---[ fin de seguimiento 5ef7896144d398e1 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: pm: solo decrementar add_addr_accepted para solicitud MPJ Agregar la siguiente advertencia ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... antes de decrementar el contador add_addr_accepted ayudó a encontrar un error al ejecutar la subprueba "eliminar un solo subflujo" de la autoprueba mptcp_join.sh. Eliminar un endpoint de 'subflujo' primero activará un RM_ADDR, luego el cierre del subflujo. Antes de este parche, y tras la recepción del RM_ADDR, el otro par intentará decrementar este add_addr_accepted. Eso no es correcto porque los subflujos adjuntos no se han creado tras la recepción de un ADD_ADDR. Una forma de resolver esto es disminuir el contador solo si el subflujo adjunto fue un MP_JOIN a una identificación remota que no era 0, e iniciado por el host que recibió el RM_ADDR.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: pm: solo marcar el extremo 'subflow' como disponible Agregar la siguiente advertencia ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... antes de decrementar el contador local_addr_used ayudó a encontrar un error al ejecutar la subprueba "eliminar una sola dirección" de las autopruebas mptcp_join.sh. Eliminar un extremo 'señal' activará la eliminación de todos los subflujos vinculados a este extremo a través de mptcp_pm_nl_rm_addr_or_subflow() con rm_type == MPTCP_MIB_RMSUBFLOW. Esto decrementará el contador local_addr_used, lo cual es incorrecto en este caso porque este contador está vinculado a extremos 'subflow', y aquí es un extremo 'señal' el que se está eliminando. Ahora, el contador se reduce solo si el ID se usa fuera de mptcp_pm_nl_rm_addr_or_subflow(), solo para los puntos finales de 'subflujo' y, si el ID no es 0, local_addr_used no los tiene en cuenta. Esto marca el ID como disponible y la reducción se realiza sin importar si un subflujo que usa este ID está disponible actualmente, porque el subflujo podría haberse cerrado antes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: char: xillybus: Comprobar los endpoints USB al sondear el dispositivo Asegúrese de que, mientras el controlador sondea el dispositivo, todos los endpoints a los que el controlador puede intentar acceder existan y sean del tipo correcto. Todos los dispositivos XillyUSB deben tener un endpoint Bulk IN y Bulk OUT en la dirección 1. Esto se verifica en xillyusb_setup_base_eps(). Además de eso, un dispositivo XillyUSB puede tener endpoints Bulk OUT adicionales. La información sobre las direcciones de estos endpoints se deduce de una estructura de datos (IDT) que el controlador obtiene del dispositivo mientras lo sondea. Estos endpoints se comprueban en setup_channels(). Un dispositivo XillyUSB nunca tiene más de un endpoint IN, ya que todos los datos hacia el host se multiplexan en este único endpoint Bulk IN. Es por eso que setup_channels() solo comprueba los endpoints OUT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Tomar bloqueo de estado durante el tiempo de espera de la transmisión El reportero mlx5e_safe_reopen_channels() requiere que se tome el bloqueo de estado. El cambio al que se hace referencia en la etiqueta Fixes eliminó el bloqueo para solucionar otro problema. Este parche lo vuelve a agregar, pero en un momento posterior (al llamar a mlx5e_safe_reopen_channels()) para evitar el bloqueo al que se hace referencia en la etiqueta Fixes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netem: corregir valor de retorno si falla la puesta en cola duplicada Hay un error en netem_enqueue() introducido por el commit 5845f706388a ("net: netem: corregir BUG_ON de longitud de skb en __skb_to_sgvec") que puede provocar un use-after-free. Esta confirmación hizo que netem_enqueue() siempre devolviera NET_XMIT_SUCCESS cuando se duplica un paquete, lo que puede provocar que el q.qlen de la qdisc padre se incremente por error. Cuando esto sucede, es posible que qlen_notify() se omita en el padre durante la destrucción, dejando un puntero colgante para algunas qdisc con clase como DRR. Hay dos formas en las que ocurre el error: - Si el paquete duplicado se descarta mediante rootq->enqueue() y luego también se descarta el paquete original. - Si rootq->enqueue() envía el paquete duplicado a una qdisc diferente y se descarta el paquete original, en ambos casos se devuelve NET_XMIT_SUCCESS aunque no haya paquetes en cola en la qdisc netem. La solución es posponer la puesta en cola del paquete duplicado hasta que se haya garantizado que el paquete original devolverá NET_XMIT_SUCCESS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: inicializar extack antes de su uso. Se corrige la inicialización faltante de extack en la descarga de flujo.

Las versiones 24.4.1, 23.6.6 y anteriores de Audition se ven afectadas por una vulnerabilidad de escritura fuera de los límites que podría provocar la ejecución de código arbitrario en el contexto del usuario actual. Para explotar este problema es necesaria la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.

Se descubrió una vulnerabilidad de control de acceso en la sección Informes debido a que una restricción de acceso específica no se aplica correctamente para los usuarios con privilegios limitados. Si un usuario conectado con privilegios de informes aprende a crear una solicitud de aplicación específica, podría realizar cambios limitados en la configuración de informes. Esto podría provocar una pérdida parcial de la integridad de los datos. En las instancias de Guardian/CMC con una configuración de informes, podría haber impactos limitados de denegación de servicio (DoS), ya que los informes podrían no llegar a su destino previsto, y también podría haber impactos limitados de divulgación de información. Además, modificar el servidor SMTP de destino para los informes podría provocar la vulneración de credenciales externas, ya que podrían enviarse a un servidor no autorizado.

CWE-269: Existe una vulnerabilidad de administración inadecuada de privilegios que podría causar acceso no autorizado, pérdida de confidencialidad, integridad y disponibilidad de la estación de trabajo cuando un usuario autenticado que no es administrador intenta realizar una escalada de privilegios alterando los binarios.

Halo es una herramienta de código abierto para la creación de sitios web. Se ha identificado una vulnerabilidad de seguridad en versiones anteriores a la 2.19.0 del proyecto Halo. Esta vulnerabilidad permite a un atacante ejecutar scripts maliciosos en el navegador del usuario a través de código HTML y JavaScript específico, lo que puede derivar en un ataque Cross-Site Scripting (XSS). Esta vulnerabilidad se ha corregido en la versión 2.19.0.

La confusión de tipos en la versión 8 de Google Chrome anterior a la 128.0.6613.137 permitía a un atacante remoto explotar potencialmente la corrupción de objetos a través de una página HTML manipulada. (Gravedad de seguridad de Chromium: Alta)