Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.

Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

Vulnerabilidad en CVE-2018-0197 (CVE-2018-0197)
Severidad: MEDIA
Fecha de publicación: 05/10/2018
Fecha de última actualización: 30/10/2025
Una vulnerabilidad en el subsistema VTP (VLAN Trunking Protocol) en Cisco IOS Software y Cisco IOS XE Software podría permitir que un atacante adyacente sin autenticar corrompa la base de datos VTP interna en un dispositivo afectado, provocando una denegación de servicio (DoS). La vulnerabilidad se debe a un error de lógica en cómo el software afectado gestiona un subconjunto de paquetes VTP. Un atacante podría explotar esta vulnerabilidad mediante el envío de paquetes VTP en una secuencia que desencadena un agotamiento del tiempo en el código de procesamiento del mensaje VTP del software afectado. Un exploit exitoso podría permitir que el atacante provoque un impacto en la capacidad de crear, modificar o eliminar VLAN y provoque una denegación de servicio (DoS). Existen alternativas que abordan esta vulnerabilidad. Esta vulnerabilidad afecta a dispositivos Cisco que ejecutan una versión vulnerable de Cisco IOS Software o Cisco IOS XE Software, operan en modo de cliente VTP o servidor VTP y carecen de un nombre de dominio VTP configurado. La configuración por defecto de los dispositivos Cisco que ejecutan Cisco IOS Software o Cisco IOS XE Software y soportan VTP es que operen en el modo de servidor VTP sin un nombre de dominio configurado.
Vulnerabilidad en VMware Workspace ONE Access y Identity Manager (CVE-2022-22954)
Severidad: CRÍTICA
Fecha de publicación: 11/04/2022
Fecha de última actualización: 30/10/2025
VMware Workspace ONE Access y Identity Manager contienen una vulnerabilidad de ejecución de código remota debido a una inyección de plantillas del lado del servidor. Un actor malicioso con acceso a la red puede desencadenar una inyección de plantillas del lado del servidor que puede resultar en la ejecución de código remota
Vulnerabilidad en Citrix ADC, Citrix Gateway y Citrix SDWAN WAN-OP (CVE-2020-8196)
Severidad: MEDIA
Fecha de publicación: 10/07/2020
Fecha de última actualización: 30/10/2025
Un control de acceso inapropiado en Citrix ADC y Citrix Gateway versiones anteriores a 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 y 10.5-70.18 y Citrix SDWAN WAN-OP versiones anteriores a 11.1.1a, 11.0.3d y 10.2.7, resulta en una divulgación de información limitada para usuarios poco privilegiados
Vulnerabilidad en Citrix ADC, Citrix Gateway, y Citrix SDWAN WAN-OP (CVE-2020-8195)
Severidad: MEDIA
Fecha de publicación: 10/07/2020
Fecha de última actualización: 30/10/2025
Una comprobación de entrada inapropiada en Citrix ADC y Citrix Gateway versiones anteriores a 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 y 10.5-70.18 y Citrix SDWAN WAN-OP versiones anteriores a 11.1.1a, 11.0.3d y 10.2.7, resulta en una divulgación de información limitada para usuarios poco privilegiados
Vulnerabilidad en endpoints de URL en Citrix ADC, Citrix Gateway, y Citrix SDWAN WAN-OP (CVE-2020-8193)
Severidad: MEDIA
Fecha de publicación: 10/07/2020
Fecha de última actualización: 30/10/2025
Un control de acceso inapropiado en Citrix ADC y Citrix Gateway versiones anteriores a 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 y 10.5-70.18 y Citrix SDWAN WAN-OP versiones anteriores a 11.1.1a, 11.0.3d y 10.2.7, permite un acceso no autenticado a determinados endpoints de URL
Vulnerabilidad en VMware Workspace ONE Access, Identity Manager y vRealize Automation (CVE-2022-22960)
Severidad: ALTA
Fecha de publicación: 13/04/2022
Fecha de última actualización: 30/10/2025
VMware Workspace ONE Access, Identity Manager y vRealize Automation contienen una vulnerabilidad de escalada de privilegios debido a permisos inapropiados en scripts de soporte. Un actor malicioso con acceso local puede escalar los privilegios a "root"
Vulnerabilidad en Windows NTFS (CVE-2021-31956)
Severidad: ALTA
Fecha de publicación: 08/06/2021
Fecha de última actualización: 30/10/2025
Una vulnerabilidad de Escalada de Privilegios en Windows NTFS
Vulnerabilidad en el servicio Voice Telephony Service Provider (VTSP) de Cisco IOS Software y Cisco IOS XE Software (CVE-2021-34705)
Severidad: MEDIA
Fecha de publicación: 23/09/2021
Fecha de última actualización: 30/10/2025
Una vulnerabilidad en el servicio Voice Telephony Service Provider (VTSP) de Cisco IOS Software y Cisco IOS XE Software podría permitir a un atacante remoto no autenticado omitir los patrones de destino configurados y marcar números arbitrarios. Esta vulnerabilidad es debido a una comprobación insuficiente de las cadenas de marcación en las interfaces de oficina de cambio de divisas (FXO). Un atacante podría explotar esta vulnerabilidad mediante el envío de una cadena de marcado malformada a un dispositivo afectado por medio del protocolo RDSI o SIP. Una explotación con éxito podría permitir al atacante llevar a cabo un fraude de peaje, resultando en un impacto financiero inesperado para los clientes afectados
Vulnerabilidad en el procesamiento del tráfico IPv6 de Cisco IOS XE Wireless Controller Software para Cisco Catalyst 9000 Family Wireless Controllers (CVE-2021-34767)
Severidad: ALTA
Fecha de publicación: 23/09/2021
Fecha de última actualización: 30/10/2025
Una vulnerabilidad en el procesamiento del tráfico IPv6 de Cisco IOS XE Wireless Controller Software para Cisco Catalyst 9000 Family Wireless Controllers podría permitir a un atacante adyacente no autenticado causar un bucle de capa 2 (L2) en una VLAN configurada, resultando en una condición de denegación de servicio (DoS) para esa VLAN. La vulnerabilidad es debido a un error lógico cuando se procesa tráfico IPv6 local de enlace específico. Un atacante podría explotar esta vulnerabilidad mediante el envío de un paquete IPv6 diseñado que fluyera hacia adentro mediante la interfaz cableada de un dispositivo afectado. Una explotación con éxito podría permitir al atacante causar caídas de tráfico en la VLAN afectada, desencadenando así una condición de DoS
Vulnerabilidad en la comprobación de los paquetes CAPWAP en el procesamiento del protocolo Control and Provisioning of Wireless Access Points (CAPWAP) de Cisco IOS XE Software para Cisco Catalyst 9000 Family Wireless Controllers (CVE-2021-34770)
Severidad: CRÍTICA
Fecha de publicación: 23/09/2021
Fecha de última actualización: 30/10/2025
Una vulnerabilidad en el procesamiento del protocolo Control and Provisioning of Wireless Access Points (CAPWAP) de Cisco IOS XE Software para Cisco Catalyst 9000 Family Wireless Controllers podría permitir a un atacante remoto no autenticado ejecutar código arbitrario con privilegios administrativos o causar una condición de denegación de servicio (DoS) en un dispositivo afectado. La vulnerabilidad es debido a un error lógico que se produce durante la comprobación de los paquetes CAPWAP. Un atacante podría explotar esta vulnerabilidad mediante el envío de un paquete CAPWAP diseñado a un dispositivo afectado. Una explotación con éxito podría permitir al atacante ejecutar código arbitrario con privilegios administrativos o causar que el dispositivo afectado se bloquee y se recargue, lo que resulta en una condición de DoS
Vulnerabilidad en EOL GeoVision (CVE-2024-6047)
Severidad: CRÍTICA
Fecha de publicación: 17/06/2024
Fecha de última actualización: 30/10/2025
Ciertos dispositivos EOL GeoVision no filtran adecuadamente la entrada del usuario para la funcionalidad específica. Los atacantes remotos no autenticados pueden aprovechar esta vulnerabilidad para inyectar y ejecutar comandos arbitrarios del sistema en el dispositivo.
Vulnerabilidad en kernel de Linux (CVE-2024-38541)
Severidad: CRÍTICA
Fecha de publicación: 19/06/2024
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of: módulo: agregar control de desbordamiento del búfer of_modalias() En of_modalias(), si el búfer es demasiado pequeño incluso para la primera llamada a snprintf(), el parámetro len se vuelve negativo y el parámetro str (si no es NULL inicialmente) apuntará más allá del final del búfer. Agregue la verificación de desbordamiento del búfer después de la primera llamada a snprintf() y corrija dicha verificación después de la llamada strlen() (teniendo en cuenta el carácter NUL de terminación).
Vulnerabilidad en HCL DRYiCE AEX (CVE-2024-30109)
Severidad: BAJA
Fecha de publicación: 28/06/2024
Fecha de última actualización: 30/10/2025
HCL DRYiCE AEX se ve afectado por la falta de protección contra el clickjacking en la aplicación web AEX. Un atacante puede utilizar múltiples capas transparentes u opacas para engañar a un usuario para que haga clic en un botón o enlace en una página distinta a la prevista.
Vulnerabilidad en HCL DRYiCE AEX (CVE-2024-30110)
Severidad: BAJA
Fecha de publicación: 28/06/2024
Fecha de última actualización: 30/10/2025
El producto HCL DRYiCE AEX se ve afectado por una vulnerabilidad de falta de validación de entrada en una aplicación web en particular. Se puede inyectar un script malicioso en un sistema que puede hacer que el sistema se comporte de maneras inesperadas.
Vulnerabilidad en HCL DRYiCE AEX (CVE-2024-30111)
Severidad: BAJA
Fecha de publicación: 28/06/2024
Fecha de última actualización: 30/10/2025
El producto HCL DRYiCE AEX se ve afectado por una vulnerabilidad de detección de raíz faltante en la aplicación móvil. La aplicación móvil se puede instalar en el dispositivo rooteado, debido a que los usuarios malintencionados pueden obtener acceso no autorizado a los dispositivos rooteados, comprometiendo la seguridad y potencialmente provocando violaciones de datos u otras actividades maliciosas.
Vulnerabilidad en HCL DRYiCE AEX (CVE-2024-30135)
Severidad: BAJA
Fecha de publicación: 28/06/2024
Fecha de última actualización: 30/10/2025
HCL DRYiCE AEX se ve potencialmente afectado por la divulgación de información confidencial en la aplicación móvil cuando se toma una instantánea.
Vulnerabilidad en HCL Nomad (CVE-2024-30130)
Severidad: BAJA
Fecha de publicación: 19/07/2024
Fecha de última actualización: 30/10/2025
El servidor HCL Nomad en Domino es vulnerable al caché que contiene información confidencial, lo que potencialmente podría brindarle a un atacante la capacidad de adquirir información confidencial.
Vulnerabilidad en HCL Nomad en Domino (CVE-2024-30128)
Severidad: ALTA
Fecha de publicación: 25/09/2024
Fecha de última actualización: 30/10/2025
El servidor HCL Nomad en Domino se ve afectado por una vulnerabilidad de proxy abierto en la que un atacante no autenticado puede ocultar su dirección IP de origen original. Esto puede permitirle a un atacante engañar al usuario para que exponga información confidencial.
Vulnerabilidad en HCL Traveler para Microsoft Outlook (CVE-2024-30134)
Severidad: MEDIA
Fecha de publicación: 26/09/2024
Fecha de última actualización: 30/10/2025
El ejecutable de HCL Traveler para Microsoft Outlook (HTMO.exe) está marcado como software potencialmente malicioso o una aplicación no reconocida.
Vulnerabilidad en HCL Nomad en Domino (CVE-2024-30132)
Severidad: BAJA
Fecha de publicación: 01/10/2024
Fecha de última actualización: 30/10/2025
El servidor HCL Nomad en Domino no configuró ciertos encabezados de seguridad HTTP de forma predeterminada, lo que podría permitir que un atacante obtenga información confidencial a través de vectores no especificados.
Vulnerabilidad en Sakai (CVE-2024-47876)
Severidad: ALTA
Fecha de publicación: 15/10/2024
Fecha de última actualización: 30/10/2025
Sakai es un entorno de colaboración y aprendizaje. A partir de la versión 23.0 y antes de la versión 23.2, los usuarios del kernel creados con el tipo roleview pueden iniciar sesión como usuarios normales. Esto puede provocar que se conceda acceso ilegal al sistema. La versión 23.3 corrige esta vulnerabilidad.
Vulnerabilidad en HCL Traveler para Microsoft Outlook (CVE-2024-30133)
Severidad: MEDIA
Fecha de publicación: 12/11/2024
Fecha de última actualización: 30/10/2025
HCL Traveler para Microsoft Outlook (HTMO) es susceptible a una vulnerabilidad de flujo de control. La aplicación no gestiona de forma adecuada su flujo de control durante la ejecución, lo que crea condiciones en las que el flujo de control puede modificarse de forma inesperada.
Vulnerabilidad en Cisco IOS Software y Cisco IOS XE Software (CVE-2025-20169)
Severidad: ALTA
Fecha de publicación: 05/02/2025
Fecha de última actualización: 30/10/2025
Una vulnerabilidad en el subsistema SNMP de Cisco IOS Software y Cisco IOS XE Software podría permitir que un atacante remoto autenticado provoque una condición de denegación de servicio (DoS) en un dispositivo afectado. Esta vulnerabilidad se debe a una gestión inadecuada de errores al analizar las solicitudes SNMP. Un atacante podría aprovechar esta vulnerabilidad enviando una solicitud SNMP manipulada a un dispositivo afectado. Una explotación exitosa podría permitir que el atacante haga que el dispositivo se recargue inesperadamente, lo que da como resultado una condición de denegación de servicio (DoS). Esta vulnerabilidad afecta a las versiones 1, 2c y 3 de SNMP. Para aprovechar esta vulnerabilidad a través de SNMP v2c o anterior, el atacante debe conocer una cadena de comunidad SNMP válida de lectura y escritura o de solo lectura para el sistema afectado. Para aprovechar esta vulnerabilidad a través de SNMP v3, el atacante debe tener credenciales de usuario SNMP válidas para el sistema afectado.
Vulnerabilidad en kernel de Linux (CVE-2025-21801)
Severidad: MEDIA
Fecha de publicación: 27/02/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ravb: Se corrige el bloqueo rtnl faltante en la ruta de suspensión/reanudación Corrija la ruta de suspensión/reanudación asegurándose de que el bloqueo rtnl se mantenga donde sea necesario. Las llamadas a las operaciones ravb_open, ravb_close y wol se deben realizar bajo el bloqueo rtnl para evitar conflictos con las operaciones ndo en curso. Sin esta corrección, se activa la siguiente advertencia: [ 39.032969] ============================= [ 39.032983] ADVERTENCIA: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down
Vulnerabilidad en kernel de Linux (CVE-2025-21802)
Severidad: MEDIA
Fecha de publicación: 27/02/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: se corrige el error al descargar controladores en paralelo. Al descargar el controlador hclge, primero intenta deshabilitar sriov para cada nodo ae_dev de hnae3_ae_dev_list. Si el usuario descarga el controlador hns3 en ese momento, debido a que elimina todos los nodos ae_dev, y puede causar errores. Pero no podemos simplemente usar hnae3_common_lock para esto. Porque en el flujo de proceso de pci_disable_sriov(), activará el flujo de eliminación de VF, que también tomará hnae3_common_lock. Para solucionarlo, introduzca un nuevo mutex para proteger el proceso de descarga.
Vulnerabilidad en kernel de Linux (CVE-2024-58072)
Severidad: ALTA
Fecha de publicación: 06/03/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtlwifi: eliminar check_buddy_priv no utilizado el commit 2461c7d60f9f ("rtlwifi: Actualizar archivo de encabezado") introdujo una lista global de estructuras de datos privados. Más tarde, el commit 26634c4b1868 ("rtlwifi Modificar bits existentes para que coincidan con la versión del proveedor 2013.02.07") comenzó a agregar los datos privados a esa lista en el momento del sondeo y agregó un gancho, check_buddy_priv para encontrar los datos privados de un dispositivo similar. Sin embargo, esa función nunca se usó. Además, aunque hay un bloqueo para esa lista, nunca se usa. Y cuando el sondeo falla, los datos privados nunca se eliminan de la lista. Esto haría que un segundo sondeo acceda a la memoria liberada. Elimine el gancho, las estructuras y los miembros no utilizados, lo que evitará la posible condición de ejecución en la lista y su corrupción durante un segundo sondeo cuando el sondeo falla.
Vulnerabilidad en kernel de Linux (CVE-2025-21825)
Severidad: MEDIA
Fecha de publicación: 06/03/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Cancelar la ejecución de bpf_timer a través de kworker para PREEMPT_RT Durante el procedimiento de actualización, cuando se sobrescribe un elemento en un htab preasignado, la liberación de old_element está protegida por el bloqueo del depósito. La razón por la que el bloqueo del depósito es necesario es que old_element ya se ha almacenado en htab->extra_elems después de que alloc_htab_elem() regrese. Si se libera old_element después de que se desbloquea el bloqueo del depósito, el elemento almacenado puede reutilizarse mediante un procedimiento de actualización concurrente y la liberación de old_element se ejecutará simultáneamente con la reutilización de old_element. Sin embargo, la invocación de check_and_free_fields() puede adquirir un bloqueo de giro que viola la regla lockdep porque su llamador ya ha mantenido un bloqueo de giro sin procesar (bloqueo del depósito). Se informará la siguiente advertencia cuando ocurra dicha ejecución: UG: scheduling while atomic: test_progs/676/0x00000003 3 locks held by test_progs/676: #0: ffffffff864b0240 (rcu_read_lock_trace){....}-{0:0}, at: bpf_prog_test_run_syscall+0x2c0/0x830 #1: ffff88810e961188 (&htab->lockdep_key){....}-{2:2}, at: htab_map_update_elem+0x306/0x1500 #2: ffff8881f4eac1b8 (&base->softirq_expiry_lock){....}-{2:2}, at: hrtimer_cancel_wait_running+0xe9/0x1b0 Modules linked in: bpf_testmod(O) Preemption disabled at: [] htab_map_update_elem+0x293/0x1500 CPU: 0 UID: 0 PID: 676 Comm: test_progs Tainted: G ... 6.12.0+ #11 Tainted: [W]=WARN, [O]=OOT_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)... Call Trace: dump_stack_lvl+0x57/0x70 dump_stack+0x10/0x20 __schedule_bug+0x120/0x170 __schedule+0x300c/0x4800 schedule_rtlock+0x37/0x60 rtlock_slowlock_locked+0x6d9/0x54c0 rt_spin_lock+0x168/0x230 hrtimer_cancel_wait_running+0xe9/0x1b0 hrtimer_cancel+0x24/0x30 bpf_timer_delete_work+0x1d/0x40 bpf_timer_cancel_and_free+0x5e/0x80 bpf_obj_free_fields+0x262/0x4a0 check_and_free_fields+0x1d0/0x280 htab_map_update_elem+0x7fc/0x1500 bpf_prog_9f90bc20768e0cb9_overwrite_cb+0x3f/0x43 bpf_prog_ea601c4649694dbd_overwrite_timer+0x5d/0x7e bpf_prog_test_run_syscall+0x322/0x830 __sys_bpf+0x135d/0x3ca0 __x64_sys_bpf+0x75/0xb0 x64_sys_call+0x1b5/0xa10 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ... Parece factible dividir la reutilización y el rellenado de extra_elems por CPU en dos partes independientes: reutilizar los extra_elems por CPU con el bloqueo del depósito mantenido y rellenar el old_element como extra_elems por CPU después de que se desbloquee el bloqueo del depósito. Sin embargo, hará que los procedimientos de sobrescritura concurrentes en la misma CPU devuelvan un error inesperado -E2BIG cuando el mapa esté lleno. Por lo tanto, el parche corrige el problema de bloqueo dividiendo la cancelación de bpf_timer en dos pasos para PREEMPT_RT: 1) use hrtimer_try_to_cancel() y verifique su valor de retorno 2) si el temporizador se está ejecutando, use hrtimer_cancel() a través de un kworker para cancelarlo nuevamente Considerando que la implementación actual de hrtimer_cancel() intentará adquirir un softirq_expiry_lock retenido cuando el temporizador actual se esté ejecutando, estos pasos anteriores son razonables. Sin embargo, también tiene desventajas. Cuando el temporizador se está ejecutando, la cancelación del temporizador se retrasa al liberar el último uref del mapa. El retraso también se puede corregir (por ejemplo, dividir la cancelación del temporizador bpf en dos partes: una parte en el ámbito bloqueado, otra en el ámbito desbloqueado), se puede revisar más tarde si es necesario. Es un poco difícil decidir la etiqueta de corrección correcta. Una razón es que el problema depende de PREEMPT_RT, que está habilitado en la versión v6.12. Teniendo en cuenta que el bloqueo softirq_expiry_lock existe desde la versión v5.4 y que bpf_timer se introdujo en la versión v5.15 --- truncado ---
Vulnerabilidad en kernel de Linux (CVE-2025-21826)
Severidad: MEDIA
Fecha de publicación: 06/03/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: rechaza la suma no coincidente de field_len con la longitud de la clave establecida La descripción de la longitud del campo proporciona la longitud de cada campo de clave separado en la concatenación, cada campo se redondea a 32 bits para calcular el ancho de la regla pipapo desde pipapo_init(). La longitud de la clave establecida proporciona el tamaño total de la clave alineada a 32 bits. La aritmética basada en registros aún permite combinar la longitud de la clave establecida y la descripción de la longitud del campo no coincidentes, p. ej., la longitud de la clave establecida 10 y la descripción del campo [ 5, 4 ], lo que lleva a un ancho de pipapo de 12.
Vulnerabilidad en kernel de Linux (CVE-2025-21926)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gso: corrección de propiedad en __udp_gso_segment. En __udp_gso_segment, el destructor de skb se elimina antes de segmentar el skb, pero la referencia del socket se mantiene intacta. Esto supone un problema si el skb original queda huérfano posteriormente, ya que podemos encontrarnos con el siguiente error: ¡ERROR del kernel en ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Rastreo de llamadas: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50 Lo anterior puede suceder después de una secuencia de eventos al usar OpenVSwitch, cuando una acción OVS_ACTION_ATTR_USERSPACE precede a una acción OVS_ACTION_ATTR_OUTPUT: 1. Se maneja OVS_ACTION_ATTR_USERSPACE (en do_execute_actions): el skb pasa por queue_gso_packets y luego __udp_gso_segment, donde se elimina su destructor. 2. Los datos de los segmentos se copian y se envían al espacio de usuario. 3. Se gestiona OVS_ACTION_ATTR_OUTPUT (en do_execute_actions) y se envía el mismo skb original a su ruta. 4. Si posteriormente se encuentra con skb_orphan, se detecta el error. Para solucionarlo, elimine también la referencia al socket en __udp_gso_segment.
Vulnerabilidad en kernel de Linux (CVE-2025-21931)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwpoison, memory_hotplug: bloquear folio antes de desasignar folio hwpoisoned Commit b15c87263a69 ("hwpoison, memory_hotplug: permitir que las páginas hwpoisoned se desconecten") añadir comprobaciones de envenenamiento de página en do_migrate_range para posibilitar la desconexión de la página hwpoisoned mediante la introducción de insulation_lru_page y try_to_unmap para la página hwpoisoned. Sin embargo, el bloqueo de folio debe mantenerse antes de llamar a try_to_unmap. Añadir esto para solucionar este problema. Se producirá una advertencia si el folio no se bloquea durante la desasignación: ------------[ cortar aquí ]------------ ¡ERROR del kernel en ./include/linux/swapops.h:400! Error interno: Oops - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 4 UID: 0 PID: 411 Comm: bash Contaminado: GW 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Contaminado: [W]=WARN Nombre del hardware: QEMU Máquina virtual QEMU, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Rastreo de llamadas: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invocar_llamada_al_sistema+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Código: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ fin de seguimiento 0000000000000000 ]---
Vulnerabilidad en kernel de Linux (CVE-2025-21932)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: abortar vma_modify() en caso de fallo de memoria insuficiente en la fusión. El resto de vma_modify() depende de que el estado de vmg permanezca intacto tras un intento de fusión. Normalmente, este es el caso; sin embargo, en el caso extremo de que un intento de fusión falle no porque el rango especificado no se pueda fusionar, sino debido a un error de memoria insuficiente al intentar confirmar la fusión, esta suposición se vuelve falsa. Esto da como resultado que vmg->start, end se modifique y, por lo tanto, los intentos posteriores de dividir el VMA se realizarán con valores de inicio/fin no válidos. Afortunadamente, es prácticamente imposible que logremos esto en la realidad, ya que requeriría un fallo de preasignación de nodos del árbol de maple que probablemente nunca ocurriría por ser "demasiado pequeño para fallar", es decir, el kernel simplemente seguiría reintentando la recuperación hasta que tuviera éxito. Sin embargo, este escenario sigue siendo teóricamente posible, y lo que estamos haciendo aquí es incorrecto, por lo que debemos corregirlo. La opción más segura, cuando ocurre este escenario, es simplemente abandonar la operación. Si no podemos asignar memoria para la fusión, tampoco podemos asignar memoria para la división (¡quizás incluso más!). Cualquier escenario donde esto ocurra estaría bajo una presión de memoria muy extrema (probablemente fatal), por lo que es mejor abandonar pronto. Por lo tanto, no hay duda de que es apropiado simplemente abandonar en este escenario. Sin embargo, en general, si es posible, nunca debemos asumir que el estado de VMG es estable después de un intento de fusión, ya que las operaciones de fusión actualizan los campos de VMG. Como resultado, también debemos aclarar esto almacenando inicio y fin en variables locales. El problema fue reportado originalmente por syzkaller y por Brad Spengler (a través de una discusión fuera de la lista), y en ambos casos se manifestó como una activación de la aserción: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). Parece que al menos un escenario en el que esto ocurre es uno en el que la fusión que se intenta se debe a una función madvise() en múltiples VMA, con este aspecto: inicio fin |<------>| |----------|------| | vma | siguiente | |----------|------| Cuando se invoca madvise_walk_vmas(), primero encontramos vma en lo anterior (determinando que prev sea igual a vma, ya que estamos desplazados hacia vma) y luego entramos en el bucle. Determinamos el final de vma que forma parte del rango que estamos ejecutando con madvise() estableciendo 'tmp' en este valor: /* Aquí vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; Luego invocamos la operación madvise() a través de visit(), permitiendo que prev se actualice para apuntar a vma como parte de la operación: /* Aquí vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Donde el puntero de la función visit() en esta instancia es madvise_vma_behavior(). Como se observa en los informes de syzkaller, en última instancia es madvise_update_vma() el que se invoca, llamando a vma_modify_flags_name() y vma_modify() a su vez. Luego, en vma_modify(), intentamos la fusión: merged = vma_merge_existing_range(vmg); if (merged) return merged; Invocamos esto con vmg->start, end establecido en start, tmp como tal: start tmp |<--->| |----------|------| | vma | next | |----------|------| Nos encontramos en el escenario correcto de fusión, pero en el que no podemos eliminar la parte central (estamos desplazados hacia vma). Aquí tenemos un caso especial donde vmg->start, end se establecen en valores quizás poco intuitivos: pretendíamos reducir la VMA central y expandir la siguiente. Esto significa que vmg->start, end se establecen en... vma->vm_start, start. Ahora, commit_merge() falla y vmg->start, end se mantienen así. Esto significa que volvemos al resto de vma_modify() ---truncated---
Vulnerabilidad en kernel de Linux (CVE-2025-21935)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rapidio: añadir comprobación de rio_add_net() en rio_scan_alloc_net(). Se debe comprobar el valor de retorno de rio_add_net(). Si falla, se debe ejecutar put_device() para liberar memoria y ceder la referencia inicializada en rio_add_net().
Vulnerabilidad en kernel de Linux (CVE-2025-21938)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrección de 'programación mientras es atómica' en mptcp_pm_nl_append_new_local_addr Si varias solicitudes de conexión intentan crear un endpoint mptcp implícito en paralelo, más de un llamador puede terminar en mptcp_pm_nl_append_new_local_addr porque ninguno encontró la dirección en local_addr_list durante su llamada a mptcp_pm_nl_get_local_id. En este caso, las llamadas new_local_addr concurrentes pueden eliminar la entrada de dirección creada por el llamador anterior. Estas eliminaciones usan synchronize_rcu, pero esto no está permitido en algunos de los contextos donde se puede llamar a esta función. Durante la recepción de paquetes, el llamador puede estar en una sección crítica de lectura de rcu y tener la preempción deshabilitada. Una pila de ejemplo: ERROR: programación mientras es atómica: swapper/2/0/0x00000302 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160) wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305) tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651) tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1)) ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254) ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636) irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) Este problema parece ser particularmente frecuente si el usuario anuncia un endpoint que tiene una dirección interna y externa diferente. Si se anuncia la dirección externa y ya existen varias conexiones, llegan varios SYN de subflujo en paralelo, lo que suele desencadenar la ejecución durante la creación de las primeras entradas de local_addr_list que contienen la dirección interna. Se soluciona omitiendo el reemplazo de una dirección local implícita existente si se llama mediante mptcp_pm_nl_get_local_id.
Vulnerabilidad en kernel de Linux (CVE-2025-21939)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/hmm: No desreferenciar punteros de página de estructura sin bloqueo de notificador Los pnfs que obtenemos de hmm_range_fault() apuntan a páginas en las que no tenemos una referencia, y la garantía de que aún están en las tablas de páginas de la CPU es que el bloqueo del notificador debe mantenerse y el seqno del notificador aún es válido. Entonces, mientras construimos la tabla sg y marcamos las páginas como accedidas/sucias, necesitamos mantener este bloqueo con un seqno validado. Sin embargo, el bloqueo está contaminado por recuperación, lo que hace que sg_alloc_table_from_pages_segment() sea inutilizable, ya que asigna memoria internamente. En su lugar, construya la tabla sg manualmente. Para el caso que no es iommu, esto podría llevar a menos coalescencias, pero si eso es un problema, se puede arreglar más adelante en el código del cursor de recursos. En el caso de iommu, toda la tabla sg puede fusionarse en una única región va de dispositivo contiguo. Esto evita marcar páginas que no son de nuestra propiedad como sucias y accedidas, y también evita desreferenciar páginas de estructura que no son de nuestra propiedad. v2: - Usar assert para comprobar si las funciones de función de enlace de hmm son válidas (Matthew Auld). - Tener en cuenta que las páginas grandes pueden cruzar los límites de rango (Matthew Auld). v3: - No comprobar innecesariamente si hay una tabla sg no liberada (Matthew Auld). - Añadir una función up_read() faltante en una ruta de error (Matthew Auld). (Seleccionado de el commit ea3e66d280ce2576664a862693d1da8fd324c317).
Vulnerabilidad en kernel de Linux (CVE-2025-21942)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: fix extent range end unlock in cow_file_range(). Ejecutar generic/751 en la rama for-next suele provocar un bloqueo como el que se muestra a continuación. Ambas se acumulan bloqueando una extensión. Esto sugiere que alguien olvidó desbloquear una extensión. INFORMACIÓN: La tarea kworker/u128:1:12 se bloqueó durante más de 323 segundos. No contaminada. 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:kworker/u128:1 estado:D pila:0 pid:12 tgid:12 ppid:2 indicadores:0x00004000 Cola de trabajo: btrfs-fixup btrfs_work_helper [btrfs] Rastreo de llamadas: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs] btrfs_work_helper+0xff/0x480 [btrfs] ? lock_release+0x178/0x2c0 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 INFO: task kworker/u134:0:184 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-btrfs-4) Call Trace: __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 find_lock_delalloc_range+0xdb/0x260 [btrfs] writepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xe7/0x260 ? srso_return_thunk+0x5/0x5f ? lock_acquire+0xd2/0x300 ? srso_return_thunk+0x5/0x5f ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 __writeback_single_inode+0x5c/0x4b0 writeback_sb_inodes+0x22d/0x550 __writeback_inodes_wb+0x4c/0xe0 wb_writeback+0x2f6/0x3f0 wb_workfn+0x32a/0x510 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Esto sucede porque tenemos otra ruta de éxito para el modo zonificado. Cuando no hay ninguna zona activa disponible, btrfs_reserve_extent() devuelve -EAGAIN. En este caso, tenemos dos reacciones. (1) Si el rango dado nunca se asigna, solo podemos esperar a que alguien complete una zona, por lo que esperamos el bit BTRFS_FS_NEED_ZONE_FINISH y reintentamos después. (2) O bien, si ya se han realizado algunas asignaciones, debemos abandonar y dejar que el llamador envíe E/S para la asignación. Esto se debe a que estas E/S pueden ser necesarias para completar una zona. El commit 06f364284794 ("btrfs: realizar la limpieza de folio correcta cuando cow_file_range() falla") movió el código de desbloqueo del interior del bucle al exterior. Por lo tanto, antes, las extensiones asignadas se desbloqueaban justo después de la asignación y, por lo tanto, antes de regresar de la función. Sin embargo, ya no se desbloquean en el caso (2) mencionado. Esto causó el bloqueo. Para solucionar el problema, modifique "end" al final del rango asignado. De esta manera, podemos salir del bucle y el mismo código de desbloqueo puede gestionar el caso correctamente.
Vulnerabilidad en kernel de Linux (CVE-2025-21944)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige un error en la trampa de smb2_lock. Si el número de bloqueos es mayor que 1, las banderas podrían tener un valor anterior. Debe comprobarse con las banderas de smb_lock, no con las banderas. Esto provocará un error en la trampa de locks_free_lock en la rutina de gestión de errores.
Vulnerabilidad en kernel de Linux (CVE-2025-21946)
Severidad: ALTA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige un error fuera de los límites en parse_sec_desc(). Si osidoffset, gsidoffset y dacloffset pueden ser mayores que el tamaño de la estructura smb_ntsd, si es menor, podría causar un error fuera de los límites de slab. Al validar sid, es necesario comprobar si incluye el tamaño del array subauth.
Vulnerabilidad en kernel de Linux (CVE-2025-21952)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: corsair-void: Actualizar los valores de la fuente de alimentación con un controlador de trabajo unificado. corsair_void_process_receiver se puede llamar desde un contexto de interrupción, y bloquear battery_mutex en él causaba un pánico del kernel. Se soluciona moviendo la sección crítica a su propio trabajo, compartiéndolo con battery_add_work y battery_remove_work para eliminar la necesidad de bloqueo.
Vulnerabilidad en kernel de Linux (CVE-2025-21975)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: gestión de errores en mlx5_chains_create_table(). En mlx5_chains_create_table(), se debe comprobar el valor de retorno de mlx5_get_fdb_sub_ns() y mlx5_get_flow_namespace() para evitar desreferencias de punteros nulos. Si alguna de las funciones falla, debe registrar un mensaje de error con mlx5_core_warn() y devolver un puntero de error.
Vulnerabilidad en kernel de Linux (CVE-2025-21976)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: hyperv_fb: Permite la eliminación ordenada del framebuffer. Cuando se desvincula un dispositivo framebuffer de Hyper-V, el controlador hyperv_fb intenta liberarlo forzosamente. Si este framebuffer está en uso, genera la siguiente advertencia y, por lo tanto, nunca se libera. [44.111220] ADVERTENCIA: CPU: 35 PID: 1882 en drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [44.111289] Rastreo de llamadas: [ 44.111290] [ 44.111291] ? show_regs+0x6c/0x80 [ 44.111295] ? __warn+0x8d/0x150 [ 44.111298] ? framebuffer_release+0x2c/0x40 [ 44.111300] ? report_bug+0x182/0x1b0 [ 44.111303] ? handle_bug+0x6e/0xb0 [ 44.111306] ? exc_invalid_op+0x18/0x80 [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20 [ 44.111311] ? framebuffer_release+0x2c/0x40 [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb] [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus] [ 44.111323] device_remove+0x40/0x80 [ 44.111325] device_release_driver_internal+0x20b/0x270 [ 44.111327] ? bus_find_device+0xb3/0xf0. Solucione esto trasladando la liberación del framebuffer y la memoria asociada a la función fb_ops.fb_destroy, para que el framework del framebuffer lo gestione correctamente. Mientras lo solucionamos, también reemplace el registro/desregistro manual del framebuffer con devm_register_framebuffer.
Vulnerabilidad en kernel de Linux (CVE-2025-21977)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: hyperv_fb: Se corrige el bloqueo del kernel kdump en máquinas virtuales Hyper-V Gen 2. Las máquinas virtuales Hyper-V Gen 2 arrancan mediante EFI y tienen un dispositivo de búfer de trama EFI estándar. Cuando el kernel kdump se ejecuta en una máquina virtual de este tipo, la carga del controlador efifb puede bloquearse debido al acceso al búfer de trama en la dirección de memoria incorrecta. Esto ocurre cuando el controlador hyperv_fb del kernel original mueve el búfer de trama a una dirección MMIO diferente debido a conflictos con un controlador efifb o simplefb ya en ejecución. El controlador hyperv_fb informa a Hyper-V del cambio, permitido por el protocolo de dispositivo VMBus de Hyper-V FB. Sin embargo, cuando el comando kexec carga el kernel kdump en la memoria de fallos mediante la llamada al sistema kexec_file_load(), esta desconoce el desplazamiento del framebuffer y configura el screen_info de kdump con la dirección original del framebuffer. La transición al kernel kdump no pasa por el host de Hyper-V, por lo que Hyper-V no restablece la dirección del framebuffer como lo haría al reiniciar. Cuando efifb intenta ejecutarse, accede a una dirección de framebuffer inexistente, lo que redirige al host de Hyper-V. Tras varios accesos de este tipo, el host de Hyper-V considera que el invitado es malicioso y lo limita hasta el punto de que se ejecuta muy lentamente o parece haberse colgado. Cuando el kernel kdump se carga en la memoria de fallos mediante la llamada al sistema kexec_load(), el problema no se produce. En este caso, el comando kexec crea la tabla screen_info en el espacio de usuario a partir de los datos devueltos por el comando ioctl FBIOGET_FSCREENINFO contra /dev/fb0, lo que le asigna la nueva ubicación del framebuffer. Este problema se reportó originalmente en 2020 [1], lo que resultó en el commit 3cb73bc3fa2a ("hyperv_fb: Actualizar screen_info tras eliminar el framebuffer antiguo"). Esta confirmación solucionó el problema estableciendo orig_video_isVGA a 0, por lo que el kernel de kdump desconocía el framebuffer EFI. El controlador efifb no intentó cargarse y no se produjo ningún bloqueo. Sin embargo, en 2024, el commit c25a19afb81c ("fbdev/hyperv_fb: No borrar la información global del screen_info") revirtió eficazmente el problema 3cb73bc3fa2a. el commit c25a19afb81c no hace referencia a 3cb73bc3fa2a, por lo que quizás se realizó sin conocer las implicaciones reportadas con 3cb73bc3fa2a. En cualquier caso, a partir de el commit c25a19afb81c, el problema original reapareció. Curiosamente, el controlador hyperv_drm no presenta este problema porque nunca mueve el framebuffer. La diferencia radica en que el controlador hyperv_drm elimina cualquier framebuffer conflictivo *antes* de asignar una dirección MMIO, mientras que el controlador hyperv_fb lo hace *después* de asignar una dirección MMIO. Con la ordenación "después", hyperv_fb puede encontrar un conflicto y mover el framebuffer a una dirección MMIO diferente. Sin embargo, el conflicto es esencialmente falso porque se elimina unas líneas de código más adelante. En lugar de corregir el problema con el enfoque de 2020 en el commit 3cb73bc3fa2a, se recomienda reordenar ligeramente los pasos en hyperv_fb para eliminar los framebuffers conflictivos antes de asignar una dirección MMIO. De esta forma, la dirección MMIO predeterminada del framebuffer siempre estará disponible y nunca habrá confusión sobre qué dirección debe usar el kernel de kdump: siempre es la dirección original proporcionada por el host de Hyper-V. Este enfoque ya lo utiliza el controlador hyperv_drm y es coherente con las directrices de uso que se indican al principio del módulo con la función aperture_remove_conflicting_devices(). Este enfoque también resuelve un problema menor relacionado cuando se utiliza kexec_load() para cargar el kernel de kdump. Con el código actual, desvincular y volver a vincular el controlador hyperv_fb podría---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-21978)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/hyperv: Se soluciona la fuga de espacio de direcciones al eliminar un dispositivo DRM de Hyper-V. Al sondear un dispositivo DRM de Hyper-V, el controlador asigna espacio MMIO para la VRAM y lo asigna como caché. Si se elimina el dispositivo, o si se encuentra en la ruta de error para el sondeo del dispositivo, se libera el espacio MMIO, pero no se desasigna. En consecuencia, se filtra el espacio de direcciones del kernel para la asignación. Para solucionar esto, agregue llamadas a iounmap() en la ruta de eliminación del dispositivo y en la ruta de error durante el sondeo del dispositivo.
Vulnerabilidad en kernel de Linux (CVE-2025-21983)
Severidad: ALTA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab/kvfree_rcu: Cambiar a WQ_MEM_RECLAIM wq Actualmente, las API kvfree_rcu() utilizan una cola de trabajo del sistema que es "system_unbound_wq" para controlar la maquinaria RCU para recuperar una memoria. Recientemente, se ha observado la siguiente advertencia del kernel: workqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work ADVERTENCIA: CPU: 21 PID: 330 en kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120 Módulos vinculados: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) ... CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: GE 6.13.2-0_g925d379822da #1 Nombre del hardware: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 01/02/2023 Cola de trabajo: nvme-wq nvme_scan_work RIP: 0010:check_flush_dependency+0x112/0x120 Código: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 ... RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082 RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027 RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88 RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400 R13: 0000000000000000 R14: ffff88907f420fb8 R15: 000000000000000 FS: 0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000 CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0 PKRU: 55555554 Seguimiento de llamadas: ? __warn+0xa4/0x140 ? check_flush_dependency+0x112/0x120 ? report_bug+0xe1/0x140 ? check_flush_dependency+0x112/0x120 ? handle_bug+0x5e/0x90 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? temporizador_recalc_próxima_expiración+0x190/0x190 ? comprobación_vaciado_dependencia+0x112/0x120 ? check_flush_dependency+0x112/0x120 __flush_work.llvm.1643880146586177030+0x174/0x2c0 flush_rcu_work+0x28/0x30 kvfree_rcu_barrier+0x12f/0x160 kmem_cache_destroy+0x18/0x120 bioset_exit+0x10c/0x150 disk_release.llvm.6740012984264378178+0x61/0xd0 device_release+0x4f/0x90 kobject_put+0x95/0x180 nvme_put_ns+0x23/0xc0 nvme_remove_invalid_namespaces+0xb3/0xd0 nvme_scan_work+0x342/0x490 process_scheduled_works+0x1a2/0x370 work_thread+0x2ff/0x390 ? pwq_release_workfn+0x1e0/0x1e0 kthread+0xb1/0xe0 ? __kthread_parkme+0x70/0x70 ret_from_fork+0x30/0x40 ? __kthread_parkme+0x70/0x70 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- Para solucionar esto, se cambia al uso de la cola de trabajo independiente WQ_MEM_RECLAIM, de modo que no se violen las reglas desde la perspectiva del marco de trabajo de la cola de trabajo. Además, dado que kvfree_rcu() recupera memoria, conviene usar el tipo de cola de trabajo WQ_MEM_RECLAIM, ya que está diseñado para este propósito.
Vulnerabilidad en kernel de Linux (CVE-2025-21985)
Severidad: ALTA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrección de accesos fuera de los límites [QUÉ Y CÓMO] hpo_stream_to_link_encoder_mapping tiene un tamaño de MAX_HPO_DP2_ENCODERS(=4), pero la ubicación puede tener un tamaño de hasta 6. Por lo tanto, es necesario comparar la ubicación con MAX_HPO_DP2_ENCODERS. De igual forma, disp_cfg_stream_location puede usarse como un índice de matriz que debe ser de 0 a 5, por lo que las condiciones de ASSERT deben ser menores sin igual.
Vulnerabilidad en kernel de Linux (CVE-2025-21986)
Severidad: MEDIA
Fecha de publicación: 01/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: switchdev: Convertir cadena de notificación de bloqueo en una sin procesar Una cadena de notificación de bloqueo utiliza un semáforo de lectura y escritura para proteger la integridad de la cadena. El semáforo se adquiere para escritura al agregar o quitar notificadores a o de la cadena y se adquiere para lectura al recorrer la cadena e informar a los notificadores sobre un evento. En el caso de la cadena de notificación de bloqueo switchdev, son posibles las notificaciones recursivas, lo que lleva a que el semáforo se adquiera dos veces para lectura y a que se generen advertencias de lockdep [1]. Específicamente, esto puede suceder cuando el controlador del puente procesa un evento SWITCHDEV_BRPORT_UNOFFLOADED que hace que emita notificaciones sobre eventos diferidos al llamar a switchdev_deferred_process(). Corrija esto convirtiendo la cadena de notificación en una cadena de notificación sin procesar de manera similar a la cadena de notificación netdev. Proteja la cadena usando el mutex RTNL adquiriéndolo al modificar la cadena. Los eventos siempre se informan bajo el mutex RTNL, pero se debe añadir una aserción en call_switchdev_blocking_notifiers() para garantizar que no se viole en el futuro. Mantenga el prefijo "blocking", ya que los eventos siempre se emiten desde el contexto del proceso y los oyentes pueden bloquearlos. [1]: ADVERTENCIA: posible bloqueo recursivo detectado 6.14.0-rc4-custom-g079270089484 #1 No contaminado -------------------------------------------- ip/52731 está intentando adquirir el bloqueo: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, en: blocking_notifier_call_chain+0x58/0xa0 pero la tarea ya tiene el bloqueo: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, en: blocking_notifier_call_chain+0x58/0xa0 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock((switchdev_blocking_notif_chain).rwsem); bloquear((switchdev_bloqueo_notificación_cadena).rwsem); *** BLOQUEO INTERMEDIO *** Puede deberse a la falta de notación de anidamiento de bloqueos. 3 bloqueos mantenidos por ip/52731: #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0 #1: ffffffff8731f628 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0 #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0 stack backtrace: ... ? __pfx_down_read+0x10/0x10 ? __pfx_mark_lock+0x10/0x10 ? __pfx_switchdev_port_attr_set_deferred+0x10/0x10 blocking_notifier_call_chain+0x58/0xa0 switchdev_port_attr_notify.constprop.0+0xb3/0x1b0 ? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10 ? mark_held_locks+0x94/0xe0 ? switchdev_deferred_process+0x11a/0x340 switchdev_port_attr_set_deferred+0x27/0xd0 switchdev_deferred_process+0x164/0x340 br_switchdev_port_unoffload+0xc8/0x100 [bridge] br_switchdev_blocking_event+0x29f/0x580 [bridge] notifier_call_chain+0xa2/0x440 blocking_notifier_call_chain+0x6e/0xa0 switchdev_bridge_port_unoffload+0xde/0x1a0 ...
Vulnerabilidad en kernel de Linux (CVE-2025-21987)
Severidad: MEDIA
Fecha de publicación: 02/04/2025
Fecha de última actualización: 30/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: valor de retorno inicial en amdgpu_ttm_clear_buffer. De lo contrario, se puede devolver un valor no inicializado si amdgpu_res_cleared devuelve verdadero para todas las regiones. Posible cierre: https://gitlab.freedesktop.org/drm/amd/-/issues/3812 (seleccionado de la confirmación 7c62aacc3b452f73a1284198c81551035fac6d71).
Vulnerabilidad en Graylog (CVE-2025-30373)
Severidad: MEDIA
Fecha de publicación: 07/04/2025
Fecha de última actualización: 30/10/2025
Graylog es una plataforma de gestión de registros gratuita y abierta. A partir de la versión 6.1, las entradas HTTP se pueden configurar para comprobar si un encabezado específico está presente y tiene un valor específico para autenticar la ingesta basada en HTTP. Desafortunadamente, aunque en caso de que falte un encabezado o se muestre un valor incorrecto, se devuelve la respuesta HTTP correcta (401), el mensaje se ingiere de todas formas. Para mitigar esta vulnerabilidad, deshabilite las entradas basadas en HTTP y permita solo las entradas autenticadas basadas en pull. Esta vulnerabilidad se corrigió en la versión 6.1.9.
Vulnerabilidad en WW Norton InQuizitive (CVE-2025-32808)
Severidad: ALTA
Fecha de publicación: 11/04/2025
Fecha de última actualización: 30/10/2025
WW Norton InQuizitive hasta el 08/04/2025 permite a los estudiantes insertar registros arbitrarios de su desempeño en las pruebas en el backend, porque solo existe control de acceso del lado del cliente.
Vulnerabilidad en WW Norton InQuizitive (CVE-2025-32809)
Severidad: MEDIA
Fecha de publicación: 11/04/2025
Fecha de última actualización: 30/10/2025
WW Norton InQuizitive hasta el 8 de abril de 2025 permite a los estudiantes realizar ataques de XSS almacenado contra educadores a través de una descripción adicional, feedback.choice_fb[] o question_id.
Vulnerabilidad en Infinity de Pega Platform (CVE-2025-2160)
Severidad: ALTA
Fecha de publicación: 14/04/2025
Fecha de última actualización: 30/10/2025
Las versiones 8.4.3 a Infinity 24.2.1 de Pega Platform se ven afectadas por un problema de XSS con Mashup
Vulnerabilidad en Infinity de Pega Platform (CVE-2025-2161)
Severidad: ALTA
Fecha de publicación: 14/04/2025
Fecha de última actualización: 30/10/2025
Las versiones 7.2.1 a Infinity 24.2.1 de Pega Platform se ven afectadas por un problema de XSS con Mashup
Vulnerabilidad en HCL SX v21 (CVE-2024-30152)
Severidad: MEDIA
Fecha de publicación: 25/04/2025
Fecha de última actualización: 30/10/2025
HCL SX v21 se ve afectado por el uso de un algoritmo criptográfico débil. Un atacante podría explotar esta vulnerabilidad para acceder a información confidencial, modificar datos u otros efectos.
Vulnerabilidad en HCL Domino Volt (CVE-2022-27562)
Severidad: MEDIA
Fecha de publicación: 30/04/2025
Fecha de última actualización: 30/10/2025
La política de filtro de tipo de archivo predeterminado no seguro en HCL Domino Volt permite la carga de archivos .html y la ejecución de JavaScript no seguro en aplicaciones implementadas.
Vulnerabilidad en HCL Domino Volt (CVE-2022-42449)
Severidad: MEDIA
Fecha de publicación: 30/04/2025
Fecha de última actualización: 30/10/2025
La política de filtro de tipo de archivo predeterminado no seguro en HCL Domino Volt permite la carga de archivos .html y la ejecución de JavaScript no seguro en aplicaciones implementadas
Vulnerabilidad en HCL Domino Volt (CVE-2022-42450)
Severidad: MEDIA
Fecha de publicación: 30/04/2025
Fecha de última actualización: 30/10/2025
La depuración inadecuada de archivos SVG en HCL Domino Volt permite client-side script injection en aplicaciones implementadas.
Vulnerabilidad en HCL Leap (CVE-2023-37517)
Severidad: BAJA
Fecha de publicación: 30/04/2025
Fecha de última actualización: 30/10/2025
La falta de encabezados "sin caché" en HCL Leap permite que se almacenen en caché datos confidenciales.
Vulnerabilidad en HCL Domino Volt y Domino Leap (CVE-2023-37535)
Severidad: ALTA
Fecha de publicación: 30/04/2025
Fecha de última actualización: 30/10/2025
La lista blanca de protocolos URI insuficiente en HCL Domino Volt y Domino Leap permite la inyección de scripts a través de parámetros de consulta.
Vulnerabilidad en WPS Office (CVE-2024-57096)
Severidad: MEDIA
Fecha de publicación: 14/05/2025
Fecha de última actualización: 30/10/2025
Un problema en WPS Office anterior a la versión v.19302 permite que un atacante local obtenga información confidencial a través de un archivo manipulado.
Vulnerabilidad en LibTIFF (CVE-2025-8851)
Severidad: MEDIA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 30/10/2025
Se detectó una vulnerabilidad en LibTIFF hasta la versión 4.5.1. Este problema afecta a la función readSeparateStripsetoBuffer del archivo tools/tiffcrop.c del componente tiffcrop. Esta manipulación provoca un desbordamiento del búfer basado en la pila. Se requiere acceso local para abordar este ataque. El parche se identifica como 8a7a48d7a645992ca83062b3a1873c951661e2b3. Se recomienda aplicar un parche para solucionar este problema.