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 kernel de Linux (CVE-2024-38610)
Severidad: ALTA
Fecha de publicación: 19/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/virt/acrn: corrige las comprobaciones de PFNMAP PTE en acrn_vm_ram_map() Serie de parches "mm: mejoras en follow_pte() y correcciones en acrn follow_pte()". El parche n.º 1 soluciona varios problemas que detecté en el controlador acrn. Se compila, eso es todo lo que sé. Apreciaré algunas revisiones y pruebas por parte de la gente de acrn. El parche #2+#3 mejora follow_pte(), pasa un VMA en lugar del MM, agrega más controles de cordura y mejora la documentación. Lo probé rápidamente en x86-64 usando VM_PAT y terminó usando follow_pte(). Este parche (de 3): Actualmente no manejamos varios casos, lo que resulta en un uso peligroso de follow_pte() (anteriormente follow_pfn()). (1) No estamos verificando los permisos de escritura de PTE. ¿Quizás simplemente deberíamos requerir siempre pte_write() como lo hacemos para pin_user_pages_fast(FOLL_WRITE)? Es difícil saberlo, así que busquemos ACRN_MEM_ACCESS_WRITE por ahora. (2) No rechazamos páginas recontadas. Como no utilizamos notificadores MMU, jugar con páginas descontadas es peligroso y puede resultar en use-after-free. Asegurémonos de rechazarlos. (3) Sólo estamos ante el primer PTE de una gama mayor. Solo buscamos una PTE, pero memmap->len puede abarcar un área más grande. Recorramos todos los PTE involucrados y asegurémonos de que el rango de PFN sea realmente contiguo. Rechace todo lo demás: no podría haber funcionado de ninguna manera, y más bien utilizó PFN de acceso a los que no deberíamos acceder.
Vulnerabilidad en kernel de Linux (CVE-2024-38613)
Severidad: MEDIA
Fecha de publicación: 19/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: m68k: corrige la ejecución de bloqueo de giro en la creación de subprocesos del kernel. El cambio de contexto se encarga de retener el propietario del bloqueo correcto durante el cambio de las tareas 'anteriores' a las 'siguientes'. Esto depende de que las interrupciones permanezcan deshabilitadas durante toda la duración del cambio. Esta condición está garantizada para la creación normal de procesos y el cambio de contexto entre procesos que ya se están ejecutando, porque tanto 'anterior' como 'siguiente' ya tienen las interrupciones deshabilitadas en sus copias guardadas del registro de estado. La situación es diferente para los subprocesos del kernel recién creados. El registro de estado se establece en PS_S en copy_thread(), lo que deja la IPL en 0. Al restaurar el registro de estado del 'siguiente' subproceso en switch_to() también conocido como resume(), las interrupciones se habilitan prematuramente. resume() luego regresa a través de ret_from_kernel_thread() y Schedule_tail() donde se libera el bloqueo de la cola de ejecución (consulte Finish_task_switch() y Finish_lock_switch()). Una interrupción del temporizador que llama a Scheduler_tick() antes de que se libere el bloqueo en Finish_task_switch() encontrará el bloqueo ya tomado, con la tarea actual como propietario del bloqueo. Esto provoca una advertencia de recursividad de spinlock según lo informado por Guenter Roeck. Hasta donde puedo determinar, esta ejecución se abrió en el commit 533e6903bea0 ("m68k: split ret_from_fork(), simplifica kernel_thread()") pero no he realizado un estudio detallado de la historia del kernel, por lo que es posible que sea anterior a esa confirmación. Las interrupciones no se pueden deshabilitar en la copia del registro de estado guardado para los subprocesos del kernel (init se quejará de las interrupciones deshabilitadas cuando finalmente inicie el espacio de usuario). Deshabilite las interrupciones temporalmente al cambiar los conjuntos de registros de tareas en resume(). Tenga en cuenta que un simple oriw 0x700,%sr después de restaurar sr no es suficiente aquí; esto deja suficiente ejecución para que aún se observe la advertencia de 'recursión de spinlock'. Probado en ARAnyM y qemu (emulación Quadra 800).
Vulnerabilidad en kernel de Linux (CVE-2021-47618)
Severidad: MEDIA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9170/1: soluciona el pánico cuando kasan y kprobe están habilitados arm32 usa software para simular la instrucción reemplazada por kprobe. Algunas instrucciones pueden simularse mediante la construcción de funciones de ensamblaje. por lo tanto, antes de ejecutar la simulación de instrucciones, es necesario construir un entorno de ejecución de funciones de ensamblaje en lenguaje C mediante registros vinculantes. después de habilitar kasan, la relación de enlace de registros se destruirá, lo que provocará errores de simulación de instrucciones y provocará pánico en el kernel. La función de emulación de instrucciones de kprobe se distribuye en tres archivos: acciones-common.c acciones-arm.c acciones-thumb.c, por lo tanto, desactive KASAN al compilar estos archivos. por ejemplo, use kprobe insert en cap_capable+20 después de habilitar kasan, el código ensamblador de cap_capable es el siguiente: : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c agregue r0, r0, #108; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [ordenador personal, #144]; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108]; 0x6c e2859014 add r9, r5, #20 ...... El código ensamblador emulate_ldr después de habilitar kasan es el siguiente: c06f1384 : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c agregue r8, r2, #60; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load 4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f y sl, r5, #15 0a000001 beq c06f13bc e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, 4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 agregar r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 14 bne c06f1430 e1a06000 mov r6, r0 e2840040 agregar r0, r4, #64; 0x40 ...... cuando se ejecuta emulate_ldr para simular la instrucción ldr, se produce pánico y el registro es el siguiente: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, * pmd=00000000 Error interno: Ups: 206 [#1] La PC SMP ARM está en cap_capable+0x14/0xb0 LR está en emulate_ldr+0x50/0xc0 psr: 600d0293 sp: ecd63af8 ip: 00000004 fp: c0a7c30c r10: r9: c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Banderas: nZCv IRQ desactivadas FIQ activadas Modo SVC_3 2 Usuario de segmento ISA ARM Control: 32c5387d Tabla: 2d546400 DAC: 55555555 Proceso bash (pid: 1643, límite de pila = 0xecd60190) (cap_capable) de (kprobe_handler+0x218/0x340) (kprobe_handler) de (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) de (do_undefinstr+0x13c/0x364) (do_undefinstr) de (__ und_svc_finish+ 0x0/0x30) (__und_svc_finish) de (cap_capable+0x18/0xb0) (cap_capable) de (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) de (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) de (copy_process .constprop.5+0x16b4/ 0x25c8) (copy_process.constprop.5) de (_do_fork+0xe8/0x55c) (_do_fork) de (SyS_clone+0x1c/0x24) (SyS_clone) de (__sys_trace_return+0x0/0x10) Código: 0050a0e1 6c0080e2 0260a0e1 (f801f0e7)
Vulnerabilidad en kernel de Linux (CVE-2022-48711)
Severidad: MEDIA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tipc: mejorar las validaciones de tamaño para los registros de dominio recibidos. La función tipc_mon_rcv() permite que un nodo reciba y procese estructuras domain_record de nodos pares para rastrear sus vistas de la topología de la red. Este parche verifica que la cantidad de miembros en un registro de dominio recibido no exceda el límite definido por MAX_MON_DOMAIN, algo que de otro modo podría provocar un desbordamiento de pila. tipc_mon_rcv() se llama desde la función tipc_link_proto_rcv(), donde leemos un campo de longitud de datos de mensaje de 32 bits en un uint16. Para evitar cualquier riesgo de desbordamiento de bits, agregamos una verificación de cordura adicional en esa función. No podemos ver que eso suceda con el código actual, pero los futuros diseñadores, al desconocer este riesgo, pueden introducirlo permitiendo la entrega de búferes sk muy grandes (> 64k) desde la capa portadora. Este problema potencial fue identificado por Eric Dumazet. Esto corrige CVE-2022-0435
Vulnerabilidad en kernel de Linux (CVE-2022-48712)
Severidad: ALTA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige el manejo de errores en ext4_fc_record_modified_inode() El código actual no soluciona completamente el caso de error de krealloc(), lo que podría provocar una corrupción silenciosa de la memoria o un error del kernel. Este parche soluciona eso. También limpia alguna lógica de manejo de errores duplicada de varias funciones en el archivo fast_commit.c.
Vulnerabilidad en kernel de Linux (CVE-2022-48713)
Severidad: MEDIA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel/pt: soluciona el fallo con filtros de parada en modo de rango único. Añade una marca para !buf->single antes de llamar a pt_buffer_region_size en un lugar donde una marca faltante puede provocar un fallo del kernel. Corrige un error introducido por el commit 670638477aed ("perf/x86/intel/pt: utilizar de manera oportunista el modo de salida de rango único"), que agregó soporte para el modo de salida de rango único PT. Desde esa confirmación, si se alcanza un rango de filtro de parada PT durante el seguimiento, el kernel fallará debido a una desreferencia de puntero nulo en pt_handle_status debido a la llamada a pt_buffer_region_size sin un ToPA configurado. La confirmación que introdujo el modo de rango único protegió casi todos los usos de las variables del búfer ToPA con comprobaciones de la variable buf->single, pero omitió el caso en el que el hardware PT detuvo el seguimiento, lo que ocurre cuando la ejecución llega a un filtro de parada configurado. Se probó que al presionar un filtro de detención mientras se graba PT se registra exitosamente un seguimiento con este parche, pero falla sin este parche.
Vulnerabilidad en kernel de Linux (CVE-2022-48714)
Severidad: ALTA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: use VM_MAP en lugar de VM_ALLOC para ringbuf Después del commit 2fd3fb0be1d1 ("kasan, vmalloc: despoisone las páginas VM_ALLOC después del mapeo"), los mapeos que no sean VM_ALLOC se marcarán como accesibles en __get_vm_area_node( ) cuando KASAN está habilitado. Pero ahora el indicador para el área ringbuf es VM_ALLOC, por lo que KASAN se quejará del acceso fuera de los límites después de que regrese vmap(). Debido a que el área ringbuf se crea asignando páginas asignadas, use VM_MAP en su lugar. Después del cambio, la información en /proc/vmallocinfo también cambia de [inicio]-[fin] 24576 ringbuf_map_alloc+0x171/0x290 usuario vmalloc a [inicio]-[fin] 24576 ringbuf_map_alloc+0x171/0x290 usuario vmap
Vulnerabilidad en kernel de Linux (CVE-2022-48722)
Severidad: MEDIA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ieee802154: ca8210: Detener la fuga de skb. En caso de error, no se llama al asistente ieee802154_xmit_complete(). Sólo se llama manualmente a ieee802154_wake_queue(). Luego filtramos la estructura skb. Libere la estructura skb en caso de error antes de regresar.
Vulnerabilidad en kernel de Linux (CVE-2022-48757)
Severidad: ALTA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrige la fuga de información en /proc/net/ptype en un espacio de nombres de red, después de crear un socket de paquetes sin vincularlo a un dispositivo, los usuarios de otros espacios de nombres de red pueden observar la nueva `packet_type` agregado por este socket de paquete leyendo el archivo `/proc/net/ptype`. Esta es una fuga de información menor ya que el socket del paquete reconoce el espacio de nombres. Agregue un puntero de red en `packet_type` para mantener el espacio de nombres de red del socket de paquete correspondiente. En `ptype_seq_show`, este puntero de red debe verificarse cuando no sea NULL.
Vulnerabilidad en kernel de Linux (CVE-2022-48759)
Severidad: ALTA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rpmsg: char: corrige la ejecución entre el lanzamiento de rpmsg_ctrldev y cdev struct rpmsg_ctrldev contiene una estructura cdev. El código actual libera la estructura rpmsg_ctrldev en rpmsg_ctrldev_release_device(), pero el cdev es un objeto administrado, por lo tanto su liberación no es predecible y rpmsg_ctrldev podría liberarse antes de que el cdev se libere por completo, como se muestra en el seguimiento a continuación. [ 93.625603] ODEBUG: tipo de objeto activo libre (estado activo 0): timer_list sugerencia: retardado_work_timer_fn+0x0/0x7c [ 93.636115] ADVERTENCIA: CPU: 0 PID: 12 en lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0 [ 93.644799 ] Módulos vinculados en: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_al arm snd_soc_rt5682v [93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Contaminado: GB 5.4.163-lockdep #26 [93.723855] Nombre del hardware: Google Lazor (rev3 - 8) con LTE (DT) [93.730055] Cola de trabajo: eventos kobject_delayed_cleanup [93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [93.740216] pc: debug_print_object+0x 13c/ 0x1b0 [93.744890] lr: debug_print_object+0x13c/0x1b0 [93.749555] sp: ffffffacf5bc7940 [93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [93.758448] 27: fffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.78 5814] x17: 0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [ 93.796768] x13: 00000000000000000 x 12: ffffffd075e2b000 [ 93.802244 ] x11: 0000000000000001 x10: 0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 : 000000000000000 0 x6: 0000000000000000 [93.818676] x5: 0000000000000080 x4: 0000000000000000 [93.824152] x3: ffffffd0732a0fa4 x2: 0000000000000001 [9 3.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061 [93.835104] Rastreo de llamadas: [93.837644] debug_print_object+0x13c/0x1b0 [93.841963] __debug_check_no_obj_freed+0x25c/0x3c0 [93.846987] _freed+0x18/0x20 [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416 ] rpmsg_ctrldev_release_device+0x78/0xb8 [ 93.864445] device_release+0x84/0x168 [ 93.868310] kobject_cleanup+0x12c/0x298 [ 93.872356] kobject_delayed_cleanup+0x10/0x18 [ 93.87694 8] proceso_one_work+0x578/0x92c [ 93.881086] hilo_trabajador+0x804/0xcf8 [ 93.884963] kthread +0x2a8/0x314 [ 93.888303] ret_from_fork+0x10/0x18 La API cdev_device_add/del() se creó para solucionar este problema (consulte el commit '233ed09d7fda ("chardev: agregar función auxiliar para registrar desarrolladores de caracteres con un dispositivo de estructura")'), Úselo en lugar de cdev add/del().
Vulnerabilidad en kernel de Linux (CVE-2022-48760)
Severidad: ALTA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: core: corrige el bloqueo en usb_kill_urb agregando barreras de memoria el syzbot fuzzer ha identificado un error en el que los procesos se bloquean esperando que regrese usb_kill_urb(). Resulta que el problema no es desvincular la URB; eso funciona bien. Más bien, el problema surge cuando no se recibe la notificación de activación de que la URB ha completado. El motivo son los pedidos de acceso a la memoria en los sistemas SMP. En forma resumida, usb_kill_urb() y __usb_hcd_giveback_urb() operando simultáneamente en diferentes CPU realizan las siguientes acciones: CPU 0 CPU 1 ------------------------- --- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->rechazar); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Limitando su atención a urb->reject y urb->use_count, puede ver que el patrón general de accesos en la CPU 0 es: escribir urb->reject, luego leer urb->use_count; mientras que el patrón general de accesos en la CPU 1 es: escribir urb->use_count, luego leer urb->reject. En los círculos de modelos de memoria se hace referencia a este patrón como SB (por "Store Buffering"), y es bien sabido que sin una aplicación adecuada del orden deseado de accesos (en forma de barreras de memoria) es completamente posible que una o ambas CPU para ejecutar sus lecturas antes de sus escrituras. El resultado final será que a veces la CPU 0 ve el antiguo valor no incrementado de urb->use_count mientras que la CPU 1 ve el antiguo valor no incrementado de urb->reject. En consecuencia, la CPU 0 termina en la cola de espera y nunca se activa, lo que provoca el bloqueo observado en usb_kill_urb(). El mismo patrón de accesos ocurre en usb_poison_urb() y la ruta de falla de usb_hcd_submit_urb(). El problema se soluciona agregando barreras de memoria adecuadas. Para proporcionar un orden adecuado de acceso a la memoria en el patrón SB, se requiere una barrera completa en ambas CPU. Los accesos atomic_inc() y atomic_dec() en sí no proporcionan ningún orden de memoria, pero como están presentes, podemos usar la barrera de memoria optimizada smp_mb__after_atomic() en las distintas rutinas para obtener el efecto deseado. Este parche agrega las barreras de memoria necesarias.
Vulnerabilidad en kernel de Linux (CVE-2022-48763)
Severidad: MEDIA
Fecha de publicación: 20/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: x86: abandonar por la fuerza la virt anidada cuando se alterna el estado de SMM. Dejar por la fuerza la operación de virtualización anidada si el espacio de usuario alterna el estado de SMM mediante KVM_SET_VCPU_EVENTS o KVM_SYNC_X86_EVENTS. Si el espacio de usuario fuerza a la vCPU a salir de SMM mientras es posterior a VMXON y luego inyecta un SMI, vmx_enter_smm() sobrescribirá vmx->nested.smm.vmxon y terminará con vmxon=false y smm.vmxon=false, pero todos los demás Estado nVMX asignado. No intente manejar la transición con elegancia ya que (a) la mayoría de las transiciones no tienen sentido, por ejemplo, forzar SMM mientras se ejecuta L2, (b) no hay suficiente información para manejar todas las transiciones, por ejemplo, SVM quiere acceder al estado de guardado de SMRAM, y (c) KVM_SET_VCPU_EVENTS debe preceder a KVM_SET_NESTED_STATE durante la restauración del estado, ya que este último no permite colocar la vCPU en L2 si SMM está activo y no permite etiquetar la vCPU como posterior a VMXON en SMM si SMM no está activo. El abuso de KVM_SET_VCPU_EVENTS se manifiesta como una ADVERTENCIA y una pérdida de memoria en nVMX debido a una falla al liberar el VMCS oculto de vmcs01, pero el error va mucho más allá de una simple pérdida de memoria; por ejemplo, activar SMM mientras L2 está activo coloca la vCPU en un estado arquitectónicamente imposible. ADVERTENCIA: CPU: 0 PID: 3606 en free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [en línea] ADVERTENCIA: CPU: 0 PID: 3606 en free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx. c:2656 Módulos vinculados en: CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [en línea] RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Código: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00 Seguimiento de llamadas: kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123 kvm_vcpu_destroy arch/x86/kvm/../. ./../virt/kvm/kvm_main.c:441 [en línea] kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460 kvm_free_vcpus arch/x86 /kvm/x86.c:11564 [en línea] kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c :1217 [en línea] kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250 kvm_vm_release+0x3f/0x50 arch/x86/kvm/../.. /../virt/kvm/kvm_main.c:1273 __fput+0x286/0x9f0 fs/file_table.c:311 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [en línea] do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x4b0/0x28c0 kernel/signal.c:2862 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c :868 handle_signal_work kernel/entry/common.c:148 [en línea] exit_to_user_mode_loop kernel/entry/common.c:172 [en línea] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c :289 [en línea] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 Entry_SYSCALL_64_after_hwframe+0x44/0xae
Vulnerabilidad en kernel de Linux (CVE-2024-37356)
Severidad: MEDIA
Fecha de publicación: 21/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el desplazamiento fuera de los límites en dctcp_update_alpha(). En dctcp_update_alpha(), utilizamos un parámetro de módulo dctcp_shift_g de la siguiente manera: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... entregado_ce <<= (10 - dctcp_shift_g); Parece que syzkaller comenzó a modificar los parámetros del módulo y activó el desplazamiento fuera de los límites [0] estableciendo 100 en dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47) ; res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Limitemos el valor máximo de dctcp_shift_g mediante param_set_uint_minmax(). Con este parche: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: error de escritura: argumento no válido [0]: UBSAN: desplazamiento fuera de los límites en net/ipv4/tcp_dctcp.c:143:12 el exponente de desplazamiento 100 es demasiado grande para el tipo 'u32' de 32 bits (también conocido como 'int sin signo' ) CPU: 0 PID: 8083 Comm: syz-executor345 No contaminado 6.9.0-05151-g1b294a1f3561 #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c :468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [en línea] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 v_state_process+0x57a/0x2290 neto/ ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [en línea] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+ 0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0x ad0 net/mptcp/protocolo .c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [en línea] sock_close+0xc0/0x240 net/ socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [en línea] do_exit+0x9c8/0x2540 kernel/exit .c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [en línea] __se_sys_exit_group kernel/exit.c:1036 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:10 36 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Código: no se puede acceder a los bytes del código de operación en 0x7f6c2b50058c . RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 06 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
Vulnerabilidad en kernel de Linux (CVE-2024-38621)
Severidad: ALTA
Fecha de publicación: 21/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: stk1160: revisión de los límites fijos en stk1160_copy_video() La resta en esta condición se invierte. La ->longitud es la longitud del búfer. El ->byteused es cuántos bytes hemos copiado hasta ahora. Cuando la condición se invierte, eso significa que el resultado de la resta siempre es negativo, pero como no tiene signo, el resultado es un valor positivo muy alto. Eso significa que la verificación de desbordamiento nunca es cierta. Además, ->bytesused en realidad no funciona para este propósito porque no estamos escribiendo en "buf->mem + buf->bytesused". En cambio, las matemáticas para calcular el destino donde estamos escribiendo son un poco complicadas. Calcula el número de líneas completas ya escritas, multiplica por dos, omite una línea si es necesario para comenzar en una línea impar y agrega el desplazamiento a la línea. Para solucionar este desbordamiento del búfer, simplemente tome el destino real donde estamos escribiendo, si el desplazamiento ya está fuera de los límites imprima un error y regrese. De lo contrario, escriba hasta buf->bytes de longitud.
Vulnerabilidad en kernel de Linux (CVE-2024-38622)
Severidad: MEDIA
Fecha de publicación: 21/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: agregar verificación del puntero de la función de devolución de llamada antes de su llamada. En dpu_core_irq_callback_handler(), el puntero de la función de devolución de llamada se compara con NULL, pero luego este puntero llama incondicionalmente a la función de devolución de llamada. Corrija este error agregando devolución condicional. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. Remiendo: https://patchwork.freedesktop.org/patch/588237/
Vulnerabilidad en kernel de Linux (CVE-2024-38635)
Severidad: ALTA
Fecha de publicación: 21/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soundwire: cadencia: corrige el desplazamiento de PDI no válido. Por alguna razón, agregamos un desplazamiento al PDI, presumiblemente para omitir el PDI0 y el PDI1 que están reservados para BPT. Sin embargo, este código es completamente erróneo y conduce a un acceso fuera de los límites. Hasta ahora tuvimos suerte ya que solo usamos un par de PDI y nos mantuvimos dentro de los límites de la matriz de PDI. No se proporciona una etiqueta de Correcciones: ya que no hay plataformas conocidas donde se pueda acceder a los límites, y el código inicial también tenía problemas. Un parche de seguimiento elimina por completo esta compensación inútil.
Vulnerabilidad en kernel de Linux (CVE-2024-38637)
Severidad: MEDIA
Fecha de publicación: 21/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: greybus: luces: verificar el retorno de get_channel_from_mode Si no se encuentra el canal para el nodo dado, devolvemos nulo de get_channel_from_mode. Asegúrese de validar el puntero de retorno antes de usarlo en dos de los lugares que faltan. Esto se informó originalmente en [0]: Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
Vulnerabilidad en kernel de Linux (CVE-2024-34777)
Severidad: ALTA
Fecha de publicación: 21/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-mapping: benchmark: corregir la validación de ID de nodo Al validar los ID de nodo en map_benchmark_ioctl(), node_possible() puede recibir un argumento no válido fuera del rango [0,MAX_NUMNODES-1]. lo que lleva a: ERROR: KASAN: acceso a memoria salvaje en map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Lectura de tamaño 8 en la dirección 1fffffff8ccb6398 por tarea dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma No contaminado 6.9. 0-rc6 #37 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/ kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [en línea] arch_test_bit (arch/x86/include/asm/bitops.h:239) [en línea] _test_bit en (incluir /asm-generic/bitops/instrumented-non-atomic.h:142) [en línea] node_state (include/linux/nodemask.h:423) [en línea] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs /debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Comparar ID de nodo con límites cuerdos primero. NUMA_NO_NODE se considera un caso válido especial, lo que significa que los kthreads de evaluación comparativa no estarán vinculados a un cpuset de un nodo determinado. Encontrado por el Centro de verificación de Linux (linuxtesting.org).
Vulnerabilidad en kernel de Linux (CVE-2024-32936)
Severidad: MEDIA
Fecha de publicación: 24/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: ti: j721e-csi2rx: corrige ejecuciones al reiniciar DMA Después de que el marco se envía a DMA, puede suceder que la lista enviada no se actualice lo suficientemente pronto y la devolución de llamada de DMA se activa antes de eso. Esto puede provocar fallos del kernel, así que mueva todo a una única sección de bloqueo/desbloqueo para evitar este tipo de ejecuciones.
Vulnerabilidad en kernel de Linux (CVE-2024-37078)
Severidad: ALTA
Fecha de publicación: 25/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige un posible error en el kernel debido a la falta de indicador de escritura reescrita en espera Las escrituras destructivas en un dispositivo de bloque en el que está montado nilfs2 pueden causar un error en el kernel en la rutina de inicio de reescritura de folio/página o Rutina de fin de reescritura (__folio_start_writeback en el registro a continuación): ¡ERROR del kernel en mm/page-writeback.c:3070! Vaya: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Código: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Seguimiento de llamadas: nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x 80 ret_from_fork_asm+0x1a/0x30 Esto se debe a que cuando el escritor de registros inicia una reescritura para bloques de resumen de segmentos o un bloque súper raíz que utiliza la caché de página del dispositivo de respaldo, no espera la reescritura en curso de folios/páginas, lo que genera un estado de reescritura inconsistente. Solucione este problema esperando las reescrituras en curso al poner las publicaciones/páginas en el dispositivo de respaldo en estado de reescritura.
Vulnerabilidad en kernel de Linux (CVE-2024-39500)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sock_map: evita la ejecución entre sock_map_close y sk_psock_put sk_psock_get devolverá NULL si el recuento de psock ha llegado a 0, lo que sucederá cuando se realice la última llamada de sk_psock_put. Sin embargo, es posible que sk_psock_drop aún no haya terminado, por lo que la devolución de llamada de cierre seguirá apuntando a sock_map_close a pesar de que psock sea NULL. Esto se puede reproducir con un hilo eliminando un elemento del mapa del calcetín, mientras que el segundo crea un socket, lo agrega al mapa y lo cierra. Eso activará WARN_ON_ONCE: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 7220 en net/core/sock_map.c :1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Módulos vinculados en: CPU: 1 PID: 7220 Comm: syz-executor380 No contaminado 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Código: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP : 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: ffffbfff25f36c4 R12: ffffffff89731840 R13: 8804b587000 R14: ffff88804b587000 R15 : ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Seguimiento de llamadas: unix_release+0x87/0xc0 net /unix/af_unix.c:1048 __sock_release net/socket.c:659 [en línea] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c: 1556 [en línea] __se_sys_close fs/open.c:1541 [en línea] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86 /entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Código: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 GS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R 08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 0 R14: 0000000000000000 R15: 0000000000000000 Utilice sk_psock, que solo verificará que el puntero no esté configurado en NULL todavía, lo que solo debería suceder después de que se restablezcan las devoluciones de llamada. Si, entonces, aún se puede obtener una referencia, podemos llamar a sk_psock_stop y cancelar psock->work. Como sugirió Paolo Abeni, reordene la condición para que el flujo de control sea menos complicado. Después de ese cambio, el reproductor ya no activa WARN_ON_ONCE.
Vulnerabilidad en pgAdmin 4 (CVE-2025-2945)
Severidad: CRÍTICA
Fecha de publicación: 03/04/2025
Fecha de última actualización: 17/09/2025
Vulnerabilidad de seguridad de ejecución remota de código en pgAdmin 4 (módulos Herramienta de consulta e Implementación en la nube). La vulnerabilidad está asociada con los dos endpoints POST: /sqleditor/query_tool/download, donde el parámetro query_commited, y /cloud/deploy, donde el parámetro high_availability se pasa de forma insegura a la función eval() de Python, lo que permite la ejecución de código arbitrario. Este problema afecta a pgAdmin 4: versiones anteriores a la versión 9.2.
Vulnerabilidad en XGrammar (CVE-2025-32381)
Severidad: MEDIA
Fecha de publicación: 09/04/2025
Fecha de última actualización: 17/09/2025
XGrammar es una librería de código abierto para la generación estructurada eficiente, flexible y portátil. Antes de la versión 0.1.18, Xgrammar incluía una caché para gramáticas compiladas que mejoraba el rendimiento con el uso repetido de la misma gramática. Esta caché se almacena en memoria. Dado que la caché es ilimitada, un sistema que utiliza xgrammar puede ser utilizado de forma abusiva para saturar la memoria del host y provocar una denegación de servicio. Por ejemplo, enviar muchas solicitudes pequeñas a un servidor de inferencia LLM con esquemas JSON únicos podría provocar esta denegación de servicio. Esta vulnerabilidad se corrigió en la versión 0.1.18.
Vulnerabilidad en HedgeDoc (CVE-2025-32391)
Severidad: MEDIA
Fecha de publicación: 10/04/2025
Fecha de última actualización: 17/09/2025
HedgeDoc es una aplicación de notas de rebajas, colaborativa y en tiempo real, de código abierto. Antes de la versión 1.10.3, un archivo SVG malicioso cargado en HedgeDoc generaba la posibilidad de un XSS cuando se abría en una nueva pestaña en lugar de en el editor mismo. El XSS es posible aprovechando las capacidades JSONP de las incrustaciones de GitHub Gist. Solo las instancias con el backend de carga del sistema de archivos local o configuraciones especiales, donde las cargas se sirven desde el mismo dominio que HedgeDoc, son vulnerables. Esta vulnerabilidad se corrigió en 1.10.3. Cuando no es posible actualizar a HedgeDoc 1.10.3, los propietarios de instancias podrían agregar los siguientes encabezados para todas las rutas bajo /uploads como primera contramedida: Content-Disposition: attachment y Content-Security-Policy: default-src 'none'. Además, se deben eliminar las URL externas en el atributo script-src del encabezado Content-Security-Policy.
Vulnerabilidad en Yii (CVE-2025-32027)
Severidad: MEDIA
Fecha de publicación: 10/04/2025
Fecha de última actualización: 17/09/2025
Yii es un framework web PHP de código abierto. Antes de la versión 1.1.31, yiisoft/yii era vulnerable a XSS reflejado en escenarios específicos donde se utiliza el renderizador de errores de respaldo. Actualice yiisoft/yii a la versión 1.1.31 o superior.
Vulnerabilidad en Formie (CVE-2025-32426)
Severidad: MEDIA
Fecha de publicación: 11/04/2025
Fecha de última actualización: 17/09/2025
Formie es un complemento Craft CMS para crear formularios. Antes de la versión 2.1.44, es posible inyectar código malicioso en el contenido HTML de una notificación por correo electrónico, que luego se representa en la vista previa. No hay ningún problema al realizar el correo electrónico por medios normales (un correo electrónico entregado). Esto requeriría acceso a la configuración de notificación de correo electrónico del formulario. Esto se ha solucionado en Formie 2.1.44.
Vulnerabilidad en Formie (CVE-2025-32427)
Severidad: MEDIA
Fecha de publicación: 11/04/2025
Fecha de última actualización: 17/09/2025
Formie es un complemento Craft CMS para crear formularios. Antes de 2.1.44, al importar un formulario de JSON, si la etiqueta o el mango de campo contenía contenido malicioso, la salida no se escapó correctamente al ver una vista previa de lo que se importaría. Como las importaciones son emprendidas principalmente por usuarios que han exportado el formulario de un entorno a otro, y requerirían la manipulación directa de la exportación JSON, esto se marca como moderado. Esta vulnerabilidad no ocurrirá a menos que alguien manifeste deliberadamente con la exportación. Esta vulnerabilidad se fija en 2.1.44.
Vulnerabilidad en Signal App 7.41.4 (CVE-2025-5715)
Severidad: BAJA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 17/09/2025
Se encontró una vulnerabilidad en Signal App 7.41.4 para Android. Se ha declarado problemática. Esta vulnerabilidad afecta al código desconocido del componente Biometric Authentication Handler. La manipulación provoca la omisión de un paso crítico en la autenticación. Es posible lanzar el ataque al dispositivo físico. Es un ataque de complejidad bastante alta. Parece difícil de explotar. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.
Vulnerabilidad en File Station 5 (CVE-2025-30279)
Severidad: ALTA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 17/09/2025
Se ha informado de una vulnerabilidad de validación incorrecta de certificados que afecta a File Station 5. Si un atacante remoto obtiene una cuenta de usuario, puede explotar la vulnerabilidad para comprometer la seguridad del sistema. Ya hemos corregido la vulnerabilidad en la siguiente versión: File Station 5 5.5.6.4847 y posteriores.
Vulnerabilidad en File Station 5 (CVE-2025-33031)
Severidad: ALTA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 17/09/2025
Se ha informado de una vulnerabilidad de validación incorrecta de certificados que afecta a File Station 5. Si un atacante remoto obtiene una cuenta de usuario, puede explotar la vulnerabilidad para comprometer la seguridad del sistema. Ya hemos corregido la vulnerabilidad en la siguiente versión: File Station 5 5.5.6.4847 y posteriores.
Vulnerabilidad en File Station 5 (CVE-2025-33035)
Severidad: ALTA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 17/09/2025
Se ha informado de una vulnerabilidad de path traversal que afecta a File Station 5. Si un atacante remoto obtiene una cuenta de usuario, puede explotar la vulnerabilidad para leer el contenido de archivos o datos del sistema inesperados. Ya hemos corregido la vulnerabilidad en la siguiente versión: File Station 5 5.5.6.4847 y posteriores.
Vulnerabilidad en Gatling 136.vb_9009b_3d33a_e de Jenkins (CVE-2025-5806)
Severidad: ALTA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 17/09/2025
El complemento Gatling 136.vb_9009b_3d33a_e de Jenkins sirve informes Gatling de una manera que elude la protección de la política de seguridad de contenido introducida en Jenkins 1.641 y 1.625, lo que genera una vulnerabilidad de Cross Site Scripting (XSS) que los usuarios pueden explotar para cambiar el contenido del informe.
Vulnerabilidad en vantage6 (CVE-2025-43863)
Severidad: BAJA
Fecha de publicación: 12/06/2025
Fecha de última actualización: 17/09/2025
vantage6 es un framework de código abierto diseñado para habilitar, administrar e implementar tecnologías que mejoran la privacidad, como el aprendizaje federado y la computación multipartita. Si un atacante accede a una sesión autenticada, puede intentar forzar la contraseña del usuario mediante la función de cambio de contraseña: puede llamar a esa ruta infinitamente, lo que devolverá el mensaje de que la contraseña es incorrecta hasta que sea correcta. Esta vulnerabilidad se corrigió en la versión 4.11.
Vulnerabilidad en Vantage6 (CVE-2025-43866)
Severidad: BAJA
Fecha de publicación: 12/06/2025
Fecha de última actualización: 17/09/2025
Vantage6 es una infraestructura de código abierto para el análisis que preserva la privacidad. La clave secreta JWT en el servidor Vantage6 se genera automáticamente, a menos que el usuario la defina. Esta clave es un UUID1, que no es criptográficamente seguro, ya que es predecible hasta cierto punto. Esta vulnerabilidad se corrigió en la versión 4.11.0.
Vulnerabilidad en DeepChat (CVE-2025-55733)
Severidad: CRÍTICA
Fecha de publicación: 19/08/2025
Fecha de última actualización: 17/09/2025
DeepChat es un asistente inteligente que conecta una potente IA con tu mundo personal. Las versiones anteriores a la 0.3.1 de DeepChat presentan una vulnerabilidad de ejecución remota de código con un solo clic. Un atacante puede explotar esta vulnerabilidad insertando una URL deepchat: especialmente manipulada en cualquier sitio web, incluso uno malicioso que controle. Cuando una víctima visita dicho sitio o hace clic en el enlace, el navegador activa el controlador de URL personalizado de la aplicación (deepchat:), lo que provoca que la aplicación DeepChat inicie y procese la URL, lo que provoca la ejecución remota de código en el equipo de la víctima. Esta vulnerabilidad se corrigió en la versión 0.3.1.
Vulnerabilidad en IBM Sterling B2B Integrator e IBM Sterling File Gateway (CVE-2025-2988)
Severidad: BAJA
Fecha de publicación: 19/08/2025
Fecha de última actualización: 17/09/2025
IBM Sterling B2B Integrator e IBM Sterling File Gateway 6.0.0.0 a 6.1.2.7, 6.2.0.0 a 6.2.0.4 y 6.2.1.0 podrían revelar información confidencial del servidor a un usuario no autorizado, lo que podría contribuir a futuros ataques contra el sistema.
Vulnerabilidad en Kapsch TrafficCom (CVE-2025-25732)
Severidad: MEDIA
Fecha de publicación: 26/08/2025
Fecha de última actualización: 17/09/2025
Un control de acceso incorrecto en el componente EEPROM de Kapsch TrafficCom RIS-9160 & RIS-9260 Roadside Units (RSUs) v3.2.0.829.23, v3.8.0.1119.42, y v4.6.0.1211.28 permite a los atacantes reemplazar los hashes de contraseñas almacenados en la EEPROM con sus propios hashes, lo que lleva a la escalada de privilegios a root.
Vulnerabilidad en NotesCMS (CVE-2025-52035)
Severidad: MEDIA
Fecha de publicación: 26/08/2025
Fecha de última actualización: 17/09/2025
Una vulnerabilidad en NotesCMS, específicamente en la página /index.php?route=notes. La manipulación del título de las descripciones de servicio genera una vulnerabilidad XSS almacenada. Se confirmó la presencia del problema en el código fuente a partir de la commit 7d821a0f028b0778b245b99ab3d3bff1ac10e2d3 (con fecha del 08/05/2024) y se corrigió en la commit 95322c5121dbd7070f3bd54f2848079654a0a8ea (con fecha del 31/03/2025). El ataque puede ejecutarse en remoto.
Vulnerabilidad en NotesCMS (CVE-2025-52036)
Severidad: MEDIA
Fecha de publicación: 26/08/2025
Fecha de última actualización: 17/09/2025
Se ha detectado una vulnerabilidad en NotesCMS, clasificada como de gravedad media. Esta vulnerabilidad afecta a la página /index.php?route=categories. La manipulación del título de las descripciones de servicio genera una vulnerabilidad XSS almacenada. Se confirmó la presencia del problema en el código fuente a partir de la commit 7d821a0f028b0778b245b99ab3d3bff1ac10e2d3 (con fecha del 08/05/2024) y se corrigió en la commit 95322c5121dbd7070f3bd54f2848079654a0a8ea (con fecha del 31/03/2025). El ataque puede ejecutarse en remoto. Definición de la vulnerabilidad según CWE: CWE-79.