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 CarrierWave (CVE-2024-29034)
Severidad: MEDIA
Fecha de publicación: 24/03/2024
Fecha de última actualización: 07/11/2025
CarrierWave es una solución para carga de archivos para Rails, Sinatra y otros frameworks web Ruby. La vulnerabilidad CVE-2023-49090 no se solucionó por completo. Esta vulnerabilidad se debe al hecho de que al cargar objetos en el almacenamiento, incluido Amazon S3, es posible establecer un valor de tipo de contenido que los navegadores interpretan como diferente de lo permitido por "content_type_allowlist", al proporcionar múltiples valores separados por comas. Este valor omitido se puede utilizar para provocar XSS. Actualice a 3.0.7 o 2.2.6.
Vulnerabilidad en Classified Listing – Classified ads & Business Directory Plugin para WordPress (CVE-2024-7888)
Severidad: MEDIA
Fecha de publicación: 13/09/2024
Fecha de última actualización: 06/11/2025
El complemento Classified Listing – Classified ads & Business Directory Plugin para WordPress es vulnerable al acceso no autorizado debido a una falta de verificación de capacidad en varias funciones como export_forms(), import_forms(), update_fb_options() y muchas más en todas las versiones hasta la 3.1.7 incluida. Esto permite que atacantes autenticados, con acceso de nivel de suscriptor y superior, modifiquen formularios y otras configuraciones.
Vulnerabilidad en DCME-320-L (CVE-2024-48659)
Severidad: CRÍTICA
Fecha de publicación: 21/10/2024
Fecha de última actualización: 06/11/2025
Un problema en DCME-320-L <=9.3.2.114 permite a un atacante remoto ejecutar código arbitrario a través del componente log_u_umount.php.
Vulnerabilidad en DCME-320, DCME-520,DCME-320-L y DCME-720 (CVE-2024-52777)
Severidad: CRÍTICA
Fecha de publicación: 29/11/2024
Fecha de última actualización: 06/11/2025
DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L, <=9.3.5.26 y DCME-720 <=9.1.5.11 son vulnerables a la ejecución remota de código a través de /function/system/basic/license_update.php.
Vulnerabilidad en DCME-320, DCME-520,DCME-320-L y DCME-720 (CVE-2024-52778)
Severidad: CRÍTICA
Fecha de publicación: 29/11/2024
Fecha de última actualización: 06/11/2025
DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26 y DCME-720 <=9.1.5.11 son vulnerables a la ejecución remota de código a través de /function/audit/newstatistics/mon_stat_hist.php.
Vulnerabilidad en DCME-320, DCME-520,DCME-320-L y DCME-720 (CVE-2024-52779)
Severidad: CRÍTICA
Fecha de publicación: 29/11/2024
Fecha de última actualización: 06/11/2025
DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26 y DCME-720 <=9.1.5.11 son vulnerables a la ejecución remota de código a través de /function/audit/newstatistics/mon_stat_top10.php.
Vulnerabilidad en DCME-320, DCME-520,DCME-320-L y DCME-720 (CVE-2024-52780)
Severidad: CRÍTICA
Fecha de publicación: 29/11/2024
Fecha de última actualización: 06/11/2025
DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26 y DCME-720 <=9.1.5.11 son vulnerables a la ejecución remota de código a través de /function/system/basic/mgmt_edit.php.
Vulnerabilidad en DCME-320, DCME-520,DCME-320-L y DCME-720 (CVE-2024-52781)
Severidad: CRÍTICA
Fecha de publicación: 29/11/2024
Fecha de última actualización: 06/11/2025
DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26 y DCME-720 <=9.1.5.11 son vulnerables a la ejecución remota de código a través de /function/system/tool/traceroute.php.
Vulnerabilidad en DCME-320, DCME-520,DCME-320-L y DCME-720 (CVE-2024-52782)
Severidad: CRÍTICA
Fecha de publicación: 29/11/2024
Fecha de última actualización: 06/11/2025
DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26 y DCME-720 <=9.1.5.11 son vulnerables a la ejecución remota de código a través de /function/audit/newstatistics/mon_stat_hist_new.php.
Vulnerabilidad en Synopsys (CVE-2024-12020)
Severidad: MEDIA
Fecha de publicación: 14/03/2025
Fecha de última actualización: 07/11/2025
Existe un cross-site scripting (XSS) reflejado en los archivos JSP que se utiliza para controlar la apariencia de la aplicación. Un atacante no autenticado podría engañar a un usuario para que haga clic en un enlace manipulado y así activar la vulnerabilidad. Robar la cookie de sesión no es posible debido a las marcas de seguridad de las cookies; sin embargo, el XSS puede utilizarse para inducir a la víctima a realizar solicitudes in situ sin su conocimiento. Esta vulnerabilidad solo afecta a LogicalDOC Enterprise.
Vulnerabilidad en Synopsys (CVE-2024-54448)
Severidad: ALTA
Fecha de publicación: 14/03/2025
Fecha de última actualización: 07/11/2025
Los atacantes pueden explotar la funcionalidad de Automation Scripting para ejecutar comandos arbitrarios en el sistema operativo subyacente. Para llevar a cabo el ataque, se requiere una cuenta con privilegios de administrador o con acceso explícito para usar Automation Scripting. Esta vulnerabilidad permitiría a un atacante ejecutar comandos de su elección en el sistema operativo subyacente del servidor web que ejecuta LogicalDOC.
Vulnerabilidad en Synopsys (CVE-2024-54449)
Severidad: ALTA
Fecha de publicación: 14/03/2025
Fecha de última actualización: 07/11/2025
La API utilizada para interactuar con los documentos de la aplicación contiene dos endpoints con una vulnerabilidad que permite a un atacante autenticado escribir un archivo con contenido controlado en una ubicación arbitraria del sistema de archivos subyacente. Esto puede utilizarse para facilitar la ejecución remota de comandos (RCE). Se requiere una cuenta con privilegios de lectura y escritura en al menos un documento existente en la aplicación para explotar la vulnerabilidad. Esta vulnerabilidad permitiría a un atacante ejecutar comandos de su elección en el sistema operativo subyacente del servidor web que ejecuta LogicalDOC.
Vulnerabilidad en IROAD Dash Cam FX2 (CVE-2025-2348)
Severidad: MEDIA
Fecha de publicación: 16/03/2025
Fecha de última actualización: 06/11/2025
Se encontró una vulnerabilidad en IROAD Dash Cam FX2 hasta la versión 20250308. Se ha clasificado como problemática. Se ve afectada una función desconocida del archivo /mnt/extsd/event/ del componente HTTP/RTSP. La manipulación provoca la divulgación de información. El ataque debe iniciarse dentro de la red local. Se ha hecho público el exploit y puede que sea utilizado.
Vulnerabilidad en IROAD Dash Cam FX2 (CVE-2025-2349)
Severidad: BAJA
Fecha de publicación: 16/03/2025
Fecha de última actualización: 06/11/2025
Se encontró una vulnerabilidad en IROAD Dash Cam FX2 hasta la versión 20250308. Se ha declarado problemática. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /etc/passwd del componente Password Hash Handler. La manipulación genera un hash de contraseña con un esfuerzo computacional insuficiente. Este ataque requiere acceso a la red local. Es un ataque de complejidad bastante alta. Parece difícil de explotar. Se ha hecho público el exploit y puede que sea utilizado.
Vulnerabilidad en kernel de Linux (CVE-2025-38637)
Severidad: MEDIA
Fecha de publicación: 18/04/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: skbprio: eliminar aserciones de cola demasiado estrictas En la implementación actual, skbprio enqueue/dequeue contiene una aserción que falla bajo ciertas condiciones cuando SKBPRIO se usa como una qdisc secundaria bajo TBF con parámetros específicos. El fallo se produce porque TBF a veces echa un vistazo a los paquetes en la qdisc secundaria sin realmente sacarlos de la cola cuando los tokens no están disponibles. Esta operación de vistazo crea una discrepancia entre los contadores de longitud de cola de la qdisc primaria y secundaria. Cuando TBF recibe posteriormente un paquete de alta prioridad, la longitud de cola de SKBPRIO puede mostrar un valor diferente al que se refleja en su seguimiento interno de cola de prioridad, lo que activa la aserción. La corrección elimina estas aserciones demasiado estrictas en SKBPRIO, no son necesarias en absoluto.
Vulnerabilidad en kernel de Linux (CVE-2025-39688)
Severidad: MEDIA
Fecha de publicación: 18/04/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: permite SC_STATUS_FREEABLE al buscar mediante nfs4_lookup_stateid() La prueba pynfs DELEG8 falla cuando se ejecuta contra nfsd. Adquiere una delegación y luego deja que se agote el tiempo de concesión. Luego intenta usar el stateid de la deleg y espera ver NFS4ERR_DELEG_REVOKED, pero en su lugar obtiene NFS4ERR_BAD_STATEID incorrecto. Cuando se revoca una delegación, inicialmente se marca con SC_STATUS_REVOKED o SC_STATUS_ADMIN_REVOKED y, más tarde, se marca con el indicador SC_STATUS_FREEABLE, que indica que está esperando una llamada FREE_STATEID. nfs4_lookup_stateid() acepta una máscara de estado que incluye los indicadores de estado que se permite que tenga un stateid encontrado. Actualmente, esa máscara nunca incluye SC_STATUS_FREEABLE, lo que significa que las delegaciones revocadas (casi) nunca se encuentran. Agregue SC_STATUS_FREEABLE a los indicadores de estado siempre permitidos y elimínelo de nfsd4_delegreturn(), ya que ahora siempre está implícito.
Vulnerabilidad en kernel de Linux (CVE-2025-39930)
Severidad: MEDIA
Fecha de publicación: 18/04/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: simple-card-utils: No usar __free(device_node) en el commit 419d1918105e de graph_util_parse_dai() ("ASoC: simple-card-utils: usar __free(device_node) para el nodo de dispositivo") usa __free(device_node) para dlc->of_node, pero es necesario mantenerlo mientras se usa el controlador. No usar __free(device_node) en graph_util_parse_dai().
Vulnerabilidad en kernel de Linux (CVE-2025-39989)
Severidad: MEDIA
Fecha de publicación: 18/04/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mce: usar is_copy_from_user() para determinar el contexto de copia del usuario. Serie de parches "mm/hwpoison: Corregir regresiones en la gestión de fallos de memoria", v4. ## 1. ¿Qué intento hacer?: Este conjunto de parches resuelve dos regresiones críticas relacionadas con la gestión de fallos de memoria que han aparecido en el kernel original desde la versión 5.17, en comparación con la 5.10 LTS. - caso de copyin: se encontró un error en la página de usuario mientras el kernel copiaba desde el espacio de usuario. - caso de instr: se encontró un error al obtener instrucciones en el espacio de usuario. ## 2. ¿Cuál es el resultado esperado y por qué? - Para el caso de copyin: el kernel puede recuperarse del error encontrado donde el kernel ejecuta get_user() o copy_from_user() si en esos lugares se obtiene un error y el kernel devuelve -EFAULT al proceso en lugar de bloquearse. Más específicamente, el controlador de MCE comprueba el tipo de controlador de corrección para decidir si se puede recuperar un #MC en el kernel. Cuando se encuentra EX_TYPE_UACCESS, el PC salta al código de recuperación especificado en _ASM_EXTABLE_FAULT() y devuelve un -EFAULT al espacio de usuario. - En el caso de instr: Si se encuentra un error durante la obtención de instrucciones en el espacio de usuario, es posible una recuperación completa. El proceso de usuario toma #PF, Linux asigna una nueva página y la completa leyendo del almacenamiento. ## 3. Qué sucede realmente y por qué - En el caso de copyin: Pánico del kernel desde la v5.17. El commit 4c132d1d844a ("x86/futex: Eliminar el uso de .fixup") introdujo un nuevo tipo de corrección extable, EX_TYPE_EFAULT_REG, y parches posteriores actualizaron el tipo de corrección extable para operaciones de copia desde el usuario, cambiándolo de EX_TYPE_UACCESS a EX_TYPE_EFAULT_REG. Esto interrumpe la gestión previo de EX_TYPE_UACCESS cuando se encuentra error en get_user() o copy_from_user(). - Para el caso instr: el proceso del usuario es eliminado por una señal SIGBUS debido a la ejecución #CMCI y #MCE Cuando se consume un error de memoria sin corregir, hay una ejecución entre el CMCI del controlador de memoria que informa un error sin corregir con una firma UCNA y el informe del núcleo y la comprobación de la máquina con firma SRAR cuando los datos están a punto de consumirse. ### Antecedentes: por qué los errores *UN*corregidos están vinculados a *C*MCI en la plataforma Intel [1] Antes de Icelake, los controladores de memoria informaban de eventos de depuración de patrullaje que detectaban un error sin corregir no visto previamente en la memoria mediante la señalización de una comprobación de la máquina de difusión con una firma SRAO (Acción recuperable de software opcional) en el banco de comprobación de la máquina. Esto era excesivo porque no es un problema urgente que ningún núcleo esté a punto de consumir esos datos erróneos. También se ha descubierto que varias UCE SRAO pueden causar interrupciones MCE anidadas y, finalmente, convertirse en una IERR. Por lo tanto, Intel degrada la firma del banco de verificación de la máquina de la limpieza de patrullaje de SRAO a UCNA (sin corregir, no se requiere acción) y la señal cambia a #CMCI. Para aumentar la confusión, Linux realiza una acción (en uc_decode_notifier()) para intentar desconectar la página a pesar del nombre de la firma UC*NA*. ### Antecedentes: ¿por qué #CMCI y #MCE compiten cuando el veneno consume datos en la plataforma Intel? [1] Tras decidir que CMCI/UCNA es la mejor acción para los errores de limpieza de patrullaje, el controlador de memoria también la utiliza para las lecturas. Sin embargo, el controlador de memoria se ejecuta de forma asíncrona desde el núcleo y no puede distinguir entre una lectura "real" y una lectura especulativa. Por lo tanto, ejecutará CMCI/UCNA si se encuentra un error en cualquier lectura. Por lo tanto: 1) El núcleo es inteligente y cree que ----truncada---
Vulnerabilidad en kernel de Linux (CVE-2025-40325)
Severidad: MEDIA
Fecha de publicación: 18/04/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid10: esperar la barrera antes de devolver una solicitud de descarte con REQ_NOWAIT. raid10_handle_discard debe esperar la barrera antes de devolver una bio de descarte con REQ_NOWAIT. No es necesario imprimir un seguimiento de llamadas de advertencia si una bio de descarte tiene la bandera REQ_NOWAIT. El ingeniero de calidad suele revisar dmesg e informa de un error si dmesg tiene un seguimiento de llamadas de advertencia/error.
Vulnerabilidad en kernel de Linux (CVE-2025-23160)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: Se corrige una fuga de recursos relacionada con el dispositivo scp durante la inicialización del firmware. En dispositivos Mediatek con un procesador complementario del sistema (SCP), la estructura mtk_scp debe eliminarse explícitamente para evitar una fuga de recursos. Libere la estructura en caso de que la asignación de la estructura del firmware falle durante la inicialización.
Vulnerabilidad en kernel de Linux (CVE-2025-37750)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir UAF en descifrado con multicanal Después de la confirmación f7025d861694 ("smb: cliente: asignar criptografía solo para el servidor principal") y la confirmación b0abcd65ec54 ("smb: cliente: corregir UAF en descifrado asíncrono"), los canales comenzaron a reutilizar AEAD TFM del canal principal para realizar un descifrado sincrónico, pero eso no se puede hacer ya que podría haber varios subprocesos cifsd (uno por canal) accediendo simultáneamente a él para realizar el descifrado. Esto corrige el siguiente splat de KASAN al ejecutar fstest generic/249 con 'vers=3.1.1,multichannel,max_channels=4,seal' en Windows Server 2022: ERROR: KASAN: slab-use-after-free en gf128mul_4k_lle+0xba/0x110 Lectura de tamaño 8 en la dirección ffff8881046c18a0 por la tarea cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd No contaminado 6.15.0-rc1 #1 PREEMPT(voluntario) Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Vulnerabilidad en kernel de Linux (CVE-2025-37751)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/cpu: Evitar la ejecución al final de una tabla de erratas de AMD. El terminador de matriz NULL al final de erratum_1386_microcode se eliminó durante la migración de x86_cpu_desc a x86_cpu_id. Esto provoca que los lectores se ejecuten al final de la matriz. Reemplace el NULL.
Vulnerabilidad en kernel de Linux (CVE-2025-37754)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/huc: corrección de la valla no liberada en errores de sondeo tempranos La valla de carga retrasada de HuC, introducida con la confirmación 27536e03271da ("drm/i915/huc: rastrear la carga retrasada de HuC con una valla"), se registra con el rastreador de objetos en las primeras etapas del sondeo del controlador, pero se desregistra solo desde la eliminación del controlador, que no se llama en errores de sondeo tempranos. Dado que su memoria se asigna en devres y luego se libera de todos modos, puede suceder que se asigne nuevamente a la valla y se reutilice en futuras sondas del controlador, lo que genera advertencias del kernel que contaminan el kernel: <4> [309.731371] ------------[ cortar aquí ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] ... <4> [309.733806] ---[ fin de seguimiento 000000000000000 ]--- Este escenario se reproduce con mayor facilidad con igt@i915_module_load@reload-with-fault-injection. Solucione el problema trasladando el paso de limpieza a la ruta de la versión del controlador. (Seleccionado de la confirmación 795dbde92fe5c6996a02a5b579481de73035e7bf)
Vulnerabilidad en kernel de Linux (CVE-2025-37755)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: error en el controlador page_pool_dev_alloc_pages. page_pool_dev_alloc_pages podría devolver NULL. Se ejecutó un WARN_ON(!page), pero seguía usando el puntero NULL y se bloqueaba. Esto es similar a la confirmación 001ba0902046 ("net: fec: error en el controlador page_pool_dev_alloc_pages"). Esta vulnerabilidad fue detectada por nuestra herramienta de análisis estático Knighter.
Vulnerabilidad en kernel de Linux (CVE-2025-37759)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ublk: corrección del manejo de la recuperación y la reemisión en ublk_abort_queue(). La confirmación 8284066946e6 ("ublk: toma la referencia de la solicitud cuando la solicitud es manejada por el espacio de usuario") no toma la referencia de la solicitud en caso de reemisión de recuperación. En ese caso, la solicitud se puede volver a poner en cola y reenviar, y falla al cancelar el comando "uring". Si es una solicitud zc, la solicitud se puede liberar antes de que io_uring devuelva el buffer zc, y luego cause pánico en el kernel: [ 126.773061] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000c8 [ 126.773657] #PF: acceso de lectura del supervisor en modo kernel [ 126.774052] #PF: error_code(0x0000) - página no presente [ 126.774455] PGD 0 P4D 0 [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 No contaminado 6.14.0_blk+ #182 PREEMPT(full) [ 126.775676] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 01/04/2014 [ 126.776275] Cola de trabajo: iou_exit io_ring_exit_work [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Lo corrige tomando siempre la referencia de la solicitud para abortar la solicitud.
Vulnerabilidad en kernel de Linux (CVE-2025-37760)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vma: añadir la opción give_up_on_oom en modificar/fusionar, usar en la versión uffd Actualmente, si una fusión de VMA falla debido a una condición OOM que surge en la fusión de confirmación o un fallo al duplicar anon_vma, informamos de ello para que el llamador pueda gestionarlo. Sin embargo, hay casos en los que el llamador solo está intentando una fusión ostensiblemente y no le importa si falla debido a esta condición. Dado que no queremos introducir una suposición implícita de que solo modificamos realmente los VMA después de que puedan surgir condiciones OOM, agregue una opción 'renunciar a oom' y haga un contrato explícito de que, si se establece este indicador, no modificaremos en absoluto ningún VMA si surge OOM y simplemente nos retiraremos. Dado que sería muy inusual que un usuario intentara usar vma_modify() con este indicador activado, pero especificando un rango dentro de un VMA que termina dividiéndose (lo cual puede fallar debido a problemas con rlimit, no solo por OOM), añadimos una advertencia de depuración para esta condición. El motivo es la versión de uffd: syzkaller (y el astuto análisis de Pedro Falcato) encontró una forma en la que un fallo inyectado en la asignación, que desencadena una condición OOM al fusionar las confirmaciones, provocaba que el código de uffd se confundiera y tratara un valor de error como si fuera un puntero a un VMA. Para evitar esto, utilizamos este nuevo indicador VMG para asegurarnos de que esto nunca ocurra, aprovechando que, si borramos VMAs completas, no queremos que se nos informe de un evento OOM. Muchas gracias a Pedro Falcato por su excelente análisis y a Jann Horn por su perspicaz e inteligente análisis de la situación, ambos fundamentales en esta solución.
Vulnerabilidad en kernel de Linux (CVE-2025-37761)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: corrige un cambio fuera de los límites al invalidar TLB Cuando el tamaño del rango invalidado es mayor que rounddown_pow_of_two(ULONG_MAX), la macro de función roundup_pow_of_two(length) alcanzará un cambio fuera de los límites [1]. Use una invalidación de TLB completa para tales casos. v2: - Use una definición para el límite de tamaño de rango sobre el cual usamos una invalidación de TLB completa. (Lucas) - Use un mejor cálculo del límite. [1]: [ 39.202421] ------------[ cortar aquí ]------------ [ 39.202657] UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 [ 39.202673] el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: GU 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Nombre del hardware: Nombre del producto del sistema ASUS/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Llamada Rastreo: [ 39.202692] [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] [ 39.202970] ---[ fin del seguimiento ]--- (seleccionado de la confirmación b88f48f86500bc0b44b4f73ac66d500a40d320ad)
Vulnerabilidad en kernel de Linux (CVE-2025-37762)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/virtio: Se corrige la falta de fijación de dmabuf en la ruta de error de prepare_fb(). Se corrige el manejo de errores en prepare_fb() para corregir la pérdida de recursos cuando ocurre un error.
Vulnerabilidad en kernel de Linux (CVE-2025-37763)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: toma de referencia de trabajo emparejado. Para trabajos emparejados, el trabajo de fragmento toma una referencia en el trabajo de geometría, de modo que este no pueda liberarse hasta que el trabajo de fragmento haya terminado con él. Se accede a la estructura del trabajo de geometría cuando el programador de GPU prepara el trabajo de fragmento. Tomar la referencia impide que el trabajo de geometría se libere hasta que el trabajo de fragmento ya no la necesite. Corrige un error de use-after-free detectado por KASAN: [124.256386] ERROR: KASAN: slab-use-after-free en pvr_queue_prepare_job+0x108/0x868 [powervr] [124.264893] Lectura de tamaño 1 en la dirección ffff0000084cb960 por la tarea kworker/u16:4/63
Vulnerabilidad en kernel de Linux (CVE-2025-37764)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: se corrigen fugas de memoria del firmware. Libera la memoria utilizada para almacenar los resultados del procesamiento de la imagen del firmware al descargar el módulo. Se soluciona el problema relacionado de la fuga de la misma memoria si el procesamiento de la imagen del firmware falla durante la carga del módulo. Se garantiza la destrucción de todos los objetos GEM del firmware si falla el procesamiento de la imagen. Se corrigen las fugas de memoria detectadas por Kmemleak al descargar el módulo powervr: objeto sin referencia 0xffff000042e20000 (tamaño 94208): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE. d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H. backtrace (crc dd329dec): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xaa4/0x1f50 [powervr] unreferenced object 0xffff000042d20000 (size 20480): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................ backtrace (crc 395b02e3): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xb0c/0x1f50 [powervr]
Vulnerabilidad en kernel de Linux (CVE-2025-37774)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: slab: garantizar que slab->obj_exts esté libre en una página slab recién asignada. ktest reportó recientemente fallos al ejecutar varias pruebas de E/S con buffer con __alloc_tagging_slab_alloc_hook() en la parte superior de la pila de llamadas de fallo. La firma indica una desreferencia de dirección no válida con bits bajos de slab->obj_exts activados. Los bits estaban fuera del rango utilizado por page_memcg_data_flags y objext_flags, por lo que slab_obj_exts() no los enmascaró al obtener el puntero almacenado en slab->obj_exts. El registro de fallos típico se ve así: 00510 No se puede controlar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000010 00510 Información de aborto de memoria: 00510 ESR = 0x0000000096000045 00510 EC = 0x25: DABT (current EL), IL = 32 bits 00510 SET = 0, FnV = 0 00510 EA = 0, S1PTW = 0 00510 FSC = 0x05: level 1 translation fault 00510 Data abort info: 00510 ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000 00510 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 00510 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000 00510 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 00510 Internal error: Oops: 0000000096000045 [#1] SMP 00510 Modules linked in: 00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g189e17946605 #19327 NONE 00510 Hardware name: linux,dummy-virt (DT) 00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190 00510 lr : __kmalloc_noprof+0x150/0x310 00510 sp : ffffff80c87df6c0 00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200 00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001 00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180 00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000 00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700 00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006 00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58 00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556 00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060 00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000 00510 Call trace: 00510 __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P) 00510 __kmalloc_noprof+0x150/0x310 00510 __bch2_folio_create+0x5c/0xf8 00510 bch2_folio_create+0x2c/0x40 00510 bch2_readahead+0xc0/0x460 00510 read_pages+0x7c/0x230 00510 page_cache_ra_order+0x244/0x3a8 00510 page_cache_async_ra+0x124/0x170 00510 filemap_readahead.isra.0+0x58/0xa0 00510 filemap_get_pages+0x454/0x7b0 00510 filemap_read+0xdc/0x418 00510 bch2_read_iter+0x100/0x1b0 00510 vfs_read+0x214/0x300 00510 ksys_read+0x6c/0x108 00510 __arm64_sys_read+0x20/0x30 00510 invoke_syscall.constprop.0+0x54/0xe8 00510 do_el0_svc+0x44/0xc8 00510 el0_svc+0x18/0x58 00510 el0t_64_sync_handler+0x104/0x130 00510 el0t_64_sync+0x154/0x158 00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881) 00510 ---[ end trace 0000000000000000 ]--- 00510 Kernel panic - not syncing: Oops: Fatal exception 00510 SMP: stopping secondary CPUs 00510 Kernel Offset: disabled 00510 CPU features: 0x0000,000000e0,00000410,8240500b 00510 Límite de memoria: ninguno. La investigación indica que estos bits ya están configurados al asignar la página slab y no se ponen a cero tras la asignación. Aún no sabemos con certeza por qué estos fallos han comenzado a ocurrir recientemente, pero independientemente del motivo, es incorrecto no inicializar un campo que se utiliza posteriormente. Para solucionarlo, inicialice slab->obj_exts durante la asignación de la página slab.
Vulnerabilidad en kernel de Linux (CVE-2020-36790)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige una pérdida de memoria Olvidamos liberar new_model_number
Vulnerabilidad en kernel de Linux (CVE-2022-49762)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntfs: desbordamiento de comprobación al iterar ATTR_RECORDs El kernel itera sobre los ATTR_RECORD en el registro mft en ntfs_attr_find(). Debido a que los ATTR_RECORD están uno al lado del otro, el kernel puede obtener el siguiente ATTR_RECORD desde la dirección final del ATTR_RECORD actual, a través del campo de longitud del ATTR_RECORD actual. El problema es que durante la iteración, cuando el kernel calcula la dirección final del ATTR_RECORD actual, el kernel puede desencadenar un error de desbordamiento de enteros al ejecutar `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. Esto puede envolverse, lo que lleva a una iteración eterna en sistemas de 32 bits. Este parche lo resuelve añadiendo algunas comprobaciones en el cálculo de la dirección final del ATTR_RECORD actual durante la iteración.
Vulnerabilidad en kernel de Linux (CVE-2022-49763)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntfs: corrección del use-after-free en ntfs_attr_find(). Serie de parches "ntfs: corrección de errores sobre el atributo", v2. Este conjunto de parches corrige tres errores relacionados con el atributo en el registro: el parche 1 añade una comprobación de seguridad para garantizar que el campo attrs_offset en la primera carga de registro MFT desde el disco esté dentro de los límites. El parche 2 adelanta la comprobación de los límites de ATTR_RECORD para evitar desreferenciarlo antes de comprobar que esté dentro de los límites. El parche 3 añade una comprobación de desbordamiento para evitar un posible bucle infinito en ntfs_attr_find(). Sin los parches 1 y 2, el kernel activa la detección de use-after-free de KASAN, según lo informado por Syzkaller. Aunque uno de los parches 1 o 2 puede solucionar esto, aún necesitamos ambos. Porque el parche 1 corrige la causa raíz, y el parche 2 no solo corrige la causa directa, sino que también corrige el posible error fuera de los límites. Este parche (de 3): Syzkaller informó una lectura de use-after-free de la siguiente manera: ====================================================================== ERROR: KASAN: use-after-free en ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 Lectura de tamaño 2 en la dirección ffff88807e352009 por la tarea syz-executor153/3607 [...] Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193 ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845 ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854 mount_bdev+0x34d/0x410 fs/super.c:1400 legacy_get_tree+0x105/0x220 fs/fs_context.c:610 vfs_get_tree+0x89/0x2f0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x1326/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] La dirección con errores pertenece a la página física: page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350 head:ffffea0001f8d400 order:3 Compound_mapcount:0 Compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 0000000000000000 muerto000000000122 ffff888011842140 raw: 00000000000000000 0000000000040004 00000001ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección con errores: ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ====================================================================== El núcleo cargará el primer registro mft de $MFT/$DATA en ntfs_read_inode_mount(). Sin embargo, el problema radica en que, tras la carga, el kernel no comprueba si el campo attrs_offset es un valor válido. Más específicamente, si el campo attrs_offset es mayor que el campo bytes_allocated, podría activarse el error de lectura fuera de los límites (reportado como error de use-after-free) en ntfs_attr_find() cuando el kernel intenta acceder al atributo del registro MFT correspondiente. Este parche lo soluciona añadiendo la comprobación de validez entre los campos attrs_offset y bytes_allocated tras cargar el primer registro MFT.
Vulnerabilidad en kernel de Linux (CVE-2022-49764)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Impide la recursión del programa bpf para sondas de puntos de seguimiento sin procesar. Recibimos un informe de sysbot [1] sobre advertencias causadas por el programa bpf asociado al punto de seguimiento sin procesar contention_begin, que activaba el mismo punto de seguimiento mediante el auxiliar bpf_trace_printk, que toma el bloqueo trace_printk_lock. Llamada a Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 Esto se puede reproducir adjuntando el programa bpf como punto de seguimiento sin procesar en el punto de seguimiento contention_begin. El programa bpf llama al asistente bpf_trace_printk. Luego, al ejecutar perf bench, el código de bloqueo de giro se fuerza a tomar la ruta lenta e invocar el punto de seguimiento contention_begin. Esto se soluciona omitiendo la ejecución del programa bpf si ya se está ejecutando. Se usa el campo "activo" del programa bpf, que actualmente usan los programas trampoline por la misma razón. Se traslada bpf_prog_inc_misses_counter a syscall.c, ya que trampoline.c se compila solo para la opción CONFIG_BPF_JIT. [1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t
Vulnerabilidad en kernel de Linux (CVE-2022-49765)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/9p: uso de un spinlock dedicado para trans_fd. Copiando descaradamente la explicación del parche sugerido por Tetsuo Handa[1] (ligeramente reformulada): syzbot reporta un estado de bloqueo inconsistente en p9_req_put()[2], para p9_tag_remove() desde p9_req_put() desde el contexto IRQ, se usa spin_lock_irqsave() en "struct p9_client"->lock, pero trans_fd (no desde el contexto IRQ) usa spin_lock(). Dado que los bloqueos protegen elementos diferentes en client.c y en trans_fd.c, simplemente reemplace el bloqueo de trans_fd.c por uno nuevo específico para el transporte (el de client.c protege el IDR para las asignaciones de FID/etiqueta, mientras que el de trans_fd.c protege su propia lista de solicitudes y el campo de estado de la solicitud, que actúa como la máquina de estados del transporte).
Vulnerabilidad en kernel de Linux (CVE-2022-49766)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: Creación de la estructura nlmsgerr con comprobación de los límites. En preparación para que FORTIFY_SOURCE realice la comprobación de los límites en memcpy(), cambie de __nlmsg_put a nlmsg_put() y explique la comprobación de los límites para procesar memcpy() en una estructura de matriz flexible compuesta. Esto evita esta futura advertencia en tiempo de ejecución: memcpy: se detectó una escritura que abarca campos (tamaño 32) en un solo campo "&errmsg->msg" en net/netlink/af_netlink.c:2447 (tamaño 16).
Vulnerabilidad en kernel de Linux (CVE-2022-49767)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/trans_fd: syzbot reporta que la tarea se bloquea en p9_fd_close() [1], ya que p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close() no interrumpe las solicitudes kernel_read() de p9_fd_read() de p9_read_work() o kernel_write() de p9_fd_write() de p9_write_work() ya iniciadas. Dado que p9_socket_open() establece el indicador O_NONBLOCK, p9_mux_poll_stop() no necesita interrumpir kernel_read()/kernel_write(). Sin embargo, dado que p9_fd_open() no establece el indicador O_NONBLOCK, sino que bloquea la tubería a menos que la señal esté pendiente, p9_mux_poll_stop() necesita interrumpir kernel_read()/kernel_write() cuando el descriptor de archivo hace referencia a una tubería. En otras palabras, el descriptor de archivo de la tubería debe manejarse como si fuera un descriptor de archivo de socket. De alguna manera, necesitamos interrumpir kernel_read()/kernel_write() en las tuberías. Un cambio mínimo, que este parche está realizando, es establecer el indicador O_NONBLOCK de p9_fd_open(), ya que el indicador O_NONBLOCK no afecta la lectura/escritura de archivos normales. Pero este enfoque cambia el indicador O_NONBLOCK en los descriptores de archivo proporcionados por el espacio de usuario (lo que podría romper los programas del espacio de usuario), y el indicador O_NONBLOCK podría ser cambiado por el espacio de usuario. Sería posible establecer el indicador O_NONBLOCK cada vez que se invoca p9_fd_read()/p9_fd_write(), pero aún queda una pequeña ventana de tiempo para borrar el indicador O_NONBLOCK. Si no queremos manipular el indicador O_NONBLOCK, podríamos rodear kernel_read()/kernel_write() con set_thread_flag(TIF_SIGPENDING) y recalc_sigpending(). Dado que los trabajos de p9_read_work()/p9_write_work() son procesados por hilos del núcleo que procesan la cola de trabajo global system_wq, no se pudieron enviar señales desde hilos remotos al llamar a p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close(). Por lo tanto, sería necesario llamar a set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() cada vez si dependemos de señales para que kernel_read()/kernel_write() sea no bloqueante. [Dominique: añadir comentario a la sugerencia de Christian]
Vulnerabilidad en kernel de Linux (CVE-2022-49768)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p: trans_fd/p9_conn_cancel: eliminar el bloqueo del cliente anteriormente. syzbot informó un bloqueo doble aquí y ya no necesitamos este bloqueo después de que las solicitudes se hayan movido a la lista local: simplemente elimine el bloqueo anteriormente.
Vulnerabilidad en kernel de Linux (CVE-2022-49769)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: Comprobación de sb_bsize_shift tras leer el superbloque. A los fuzzers les gusta manipular sb_bsize_shift, pero en realidad es muy improbable que este campo se corrompa por sí solo. Sin embargo, conviene comprobarlo para evitar errores de montaje problemáticos debido a cálculos erróneos. Siempre es un valor fijo basado en el tamaño del bloque, por lo que podemos comprobar que sea el valor esperado. Probado con: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; Antes de este parche obtenemos una retirada después de [ 76.413681] gfs2: fsid=loop0.0: fatal: bloque de metadatos no válido [ 76.413681] bh = 19 (tipo: exp=5, encontrado=4) [ 76.413681] función = gfs2_meta_buffer, archivo = fs/gfs2/meta_io.c, línea = 492 y con UBSAN configurado también obtenemos quejas como [ 76.373395] UBSAN: cambio fuera de los límites en fs/gfs2/ops_fstype.c:295:19 [ 76.373815] cambio El exponente 4294967287 es demasiado grande para el tipo de 64 bits 'long unsigned int'. Después del parche, estas quejas no aparecen, el montaje falla inmediatamente y obtenemos una explicación en dmesg.
Vulnerabilidad en kernel de Linux (CVE-2022-49770)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: evita repetir el dominio cuando falla la decodificación de snaps. Al fallar la decodificación de snaps, puede que "first_realm" y "realm" apunten a la misma memoria de snaprealm. En ese caso, lo repetirá, lo que podría causar problemas aleatorios de use-after-free, BUG_ON, etc.
Vulnerabilidad en kernel de Linux (CVE-2025-37797)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: hfsc: Se corrige una vulnerabilidad de UAF en la gestión de clases. Este parche corrige una vulnerabilidad de use-after-free en la gestión de clases de qdisc HFSC. El problema se produce debido a una condición de tiempo de comprobación/tiempo de uso en hfsc_change_class() al trabajar con ciertas qdiscs secundarias como netem o codel. La vulnerabilidad funciona de la siguiente manera: 1. hfsc_change_class() verifica si una clase tiene paquetes (q.qlen != 0) 2. Luego llama a qdisc_peek_len(), que para ciertos qdiscs (por ejemplo, codel, netem) puede descartar paquetes y vaciar la cola 3. El código continúa asumiendo que la cola todavía no está vacía, agregando la clase a vttree 4. Esto rompe las suposiciones del programador HFSC de que solo las clases no vacías están en vttree 5. Más tarde, cuando se destruye la clase, esto puede llevar a un Use-After-Free La solución agrega una segunda verificación de longitud de cola después de qdisc_peek_len() para verificar que la cola no se haya vaciado.
Vulnerabilidad en kernel de Linux (CVE-2025-37798)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 06/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: codel: eliminar la comprobación de sch->q.qlen antes de qdisc_tree_reduce_backlog() Después de hacer que todas las devoluciones de llamadas ->qlen_notify() sean idempotentes, ahora es seguro eliminar la comprobación de qlen!=0 de fq_codel_dequeue() y codel_qdisc_dequeue().
Vulnerabilidad en kernel de Linux (CVE-2023-53062)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 07/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: smsc95xx: Limitar la longitud del paquete a skb->len. La longitud del paquete obtenida del descriptor puede ser mayor que la longitud real del búfer del socket. En tal caso, el skb clonado que se pasa a la pila de red filtrará el contenido de la memoria del kernel.
Vulnerabilidad en kernel de Linux (CVE-2023-53064)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 07/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: se corrige el bloqueo al reiniciar con hielo Cuando se reinicia un sistema con E810 con VF existentes, se puede observar el siguiente bloqueo. El Pid 1 está colgado en iavf_remove(), parte de un controlador de red: PID: 1 TAREA: ffff965400e5a340 CPU: 24 COMANDO: "systemd-shutdow" #0 [ffffaad04005fa50] __schedule en ffffffff8b3239cb #1 [ffffaad04005fae8] schedule en ffffffff8b323e2d #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock en ffffffff8b32cebc #3 [ffffaad04005fb80] usleep_range_state en ffffffff8b32c930 #4 [ffffaad04005fbb0] iavf_remove en ffffffffc12b9b4c [iavf] #5 [ffffaad04005fbf0] pci_device_remove en ffffffff8add7513 #6 [ffffaad04005fc10] device_release_driver_internal en ffffffff8af08baa #7 [ffffaad04005fc40] pci_stop_bus_device en ffffffff8adcc5fc #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device en ffffffff8adcc81e #9 [ffffaad04005fc70] pci_iov_remove_virtfn en ffffffff8adf9429 #10 [ffffaad04005fca8] sriov_disable en ffffffff8adf98e4 #11 [ffffaad04005fcc8] ice_free_vfs en ffffffffc04bb2c8 [ice] #12 [ffffaad04005fd10] ice_remove en ffffffffc04778fe [ice] #13 [ffffaad04005fd38] ice_shutdown en ffffffffc0477946 [ice] #14 [ffffaad04005fd50] pci_device_shutdown en ffffffff8add58f1 #15 [ffffaad04005fd70] device_shutdown en ffffffff8af05386 #16 [ffffaad04005fd98] kernel_restart en ffffffff8a92a870 #17 [ffffaad04005fda8] __do_sys_reboot en ffffffff8a92abd6 #18 [ffffaad04005fee0] do_syscall_64 en ffffffff8b317159 #19 [ffffaad04005ff08] __context_tracking_enter en ffffffff8b31b6fc #20 [ffffaad04005ff18] syscall_exit_to_user_mode en ffffffff8b31b50d #21 [ffffaad04005ff28] do_syscall_64 en ffffffff8b317169 #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe en ffffffff8b40009b RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007fffbcc55ca0 R8: 000000000000000 R9: 00007fffbcc54e90 R10: 00007fffbcc55050 R11: 00000000000000202 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b Durante el reinicio, se invocan las devoluciones de llamada de apagado de PM de todos los controladores. En iavf_shutdown(), el estado del adaptador cambia a __IAVF_REMOVE. En ice_shutdown() se ejecuta la cadena de llamadas anterior, que en algún momento llama a iavf_remove(). Sin embargo, iavf_remove() espera que el VF esté en uno de los estados __IAVF_RUNNING, __IAVF_DOWN o __IAVF_INIT_FAILED. De lo contrario, se suspende indefinidamente. Por lo tanto, si se invoca iavf_shutdown() antes que iavf_remove(), el sistema se bloqueará indefinidamente porque el adaptador ya está en el estado __IAVF_REMOVE. Para solucionar esto, regrese de iavf_remove() si el estado es __IAVF_REMOVE, como ya se explicó con iavf_shutdown().
Vulnerabilidad en Rallly (CVE-2025-47781)
Severidad: CRÍTICA
Fecha de publicación: 14/05/2025
Fecha de última actualización: 06/11/2025
Rallly es una herramienta de código abierto para la programación y la colaboración. Las versiones de la aplicación, hasta la 3.22.1 (incluida), incorporan autenticación mediante token. Cuando un usuario intenta iniciar sesión, introduce su correo electrónico y se le envía un código de 6 dígitos para completar la autenticación. Sin embargo, un token de 6 dígitos presenta una entropía débil y, al no contar con protección contra ataques de fuerza bruta, permite que un atacante no autenticado, con conocimiento de una dirección de correo electrónico válida, ataque el token por fuerza bruta en 15 minutos (fecha de caducidad) y se apodere de la cuenta asociada a dicha dirección. Todos los usuarios de las aplicaciones de Rallly se ven afectados. Si un atacante conoce la dirección de correo electrónico del usuario que se registró en la aplicación, puede apropiarse sistemáticamente de cualquier cuenta. Para que el mecanismo de autenticación sea seguro, se debe asignar al token un valor complejo de alta entropía que no pueda ser atacado por fuerza bruta en un tiempo razonable. Idealmente, se debe limitar la velocidad del endpoint /api/auth/callback/email para que los intentos de fuerza bruta sean aún más irrazonables dentro de los 15 minutos. Al momento de la publicación, no hay versiones parcheadas disponibles.
Vulnerabilidad en Dradis (CVE-2023-50786)
Severidad: MEDIA
Fecha de publicación: 05/07/2025
Fecha de última actualización: 07/11/2025
Dradis, hasta la versión 4.16.0, permite referenciar imágenes externas (recursos) mediante HTTPS, en lugar de forzar el uso de imágenes incrustadas (subidas). Esto puede ser aprovechado por un autor autorizado para intentar robar los hashes Net-NTLM de otros autores en una red de dominio Windows.
Vulnerabilidad en Dradis (CVE-2023-50458)
Severidad: BAJA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 07/11/2025
En las versiones de Dradis anteriores a 4.11.0, la Consola de Salida muestr auna cola de trabajos que puede contener información sobre los trabajos de otros usuarios.