Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

CVE-2025-37822

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: uprobes: Añadir un archivo "fence.i" faltante tras la construcción del búfer XOL. El búfer XOL (ejecución fuera de línea) se utiliza para ejecutar paso a paso las instrucciones reemplazadas para uprobes. El puerto RISC-V carecía de un archivo "fence.i" adecuado (vaciado de i$) tras la construcción del búfer XOL, lo que puede provocar la ejecución incorrecta de instrucciones obsoletas o dañadas. Esto se detectó al ejecutar las pruebas automáticas de BPF "test_progs: uprobe_autoattach, attached_probe" en Spacemit K1/X60, donde las pruebas de uprobes fallaron aleatoriamente.
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37823

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: hfsc: Se corrige también un posible UAF en hfsc_dequeue(). Al igual que en el parche anterior, también debemos proteger hfsc_dequeue(). Sin embargo, para este caso, no contamos con un reproductor fiable.
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37824

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la desreferencia del puntero NULL en tipc_mon_reinit_self() syzbot informó: tipc: Número de nodo establecido en 1055423674 Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 No contaminado 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Nombre del hardware: QEMU PC estándar (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: eventos tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [en línea] subproceso_de_trabajo+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_de_bifurcación+0x45/0x80 arch/x86/kernel/process.c:153 ret_de_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 00000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Hay una condición de ejecución entre la cola de trabajo creada al habilitar el portador y otro hilo creado al deshabilitar el portador justo después de eso, como se muestra a continuación: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncado---
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37825

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: se corrige el acceso fuera de los límites en nvmet_enable_port Al intentar habilitar un puerto que aún no tiene transporte configurado, nvmet_enable_port() usa NVMF_TRTYPE_MAX (255) para consultar la matriz de transportes, lo que provoca un acceso fuera de los límites: [ 106.058694] ERROR: KASAN: global fuera de los límites en nvmet_enable_port+0x42/0x1da [ 106.058719] Lectura de tamaño 8 en la dirección ffffffff89dafa58 por la tarea ln/632 [...] [ 106.076026] nvmet: no se admite el tipo de transporte 255 Desde la confirmación 200adac75888, NVMF_TRTYPE_MAX es el estado predeterminado según la configuración de nvmet_ports_make(). Evite esto verificando NVMF_TRTYPE_MAX antes de continuar.
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37826

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Añadir comprobación de valores nulos en ufshcd_mcq_compl_pending_transfer(). Añadir una comprobación de valores nulos para el puntero hwq devuelto por ufshcd_mcq_req_to_hwq(). Esto es similar a la corrección en el commit 74736103fb41 ("scsi: ufs: core: Corregir el problema de ejecuciones de ufshcd_abort_one").
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37827

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch Hubo un informe de error sobre una desreferencia de puntero NULL en __btrfs_add_free_space_zoned() que en última instancia ocurre debido a una conversión del perfil de metadatos predeterminado DUP a un perfil RAID1 en dos discos. El seguimiento de la pila tiene la siguiente firma: Error BTRFS (dispositivo sdc): zoned: desajuste del desplazamiento del puntero de escritura de las zonas en el perfil raid1 ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000058 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ fin del seguimiento 000000000000000 ]--- La primera línea es la más interesante aquí: Error BTRFS (dispositivo sdc): zoned: discrepancia en el desplazamiento del puntero de escritura de las zonas en el perfil RAID1. Cuando se crea un grupo de bloques RAID1 y se detecta una discrepancia en el desplazamiento del puntero de escritura entre los discos del conjunto RAID, btrfs establece el valor de alloc_offset en la longitud del grupo de bloques, marcándolo como lleno. Posteriormente, el código espera que una operación de balance evacue los datos de este grupo de bloques y solucione los problemas. Sin embargo, antes de que esto sea posible, el nuevo espacio de este grupo de bloques se contabilizará en la caché de espacio libre. ---truncado---
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37809

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: class: Fix. Acceso a punteros nulos. Las llamadas simultáneas a typec_partner_unlink_device pueden provocar una desreferencia de punteros nulos. Este parche añade un mutex para proteger los punteros de dispositivos USB y evitar este problema. Este mismo mutex protege tanto los punteros de dispositivo como el registro del dispositivo asociado.
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37810

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: comprobar que el recuento de eventos no supere la longitud del búfer de eventos. El recuento de eventos se lee del registro DWC3_GEVNTCOUNT. Se comprueba que el recuento sea cero, pero no que supere la longitud del búfer de eventos. Se comprueba que el recuento de eventos no supere la longitud del búfer de eventos, lo que evita un acceso fuera de los límites al copiar el evento a memoria. Registro de fallos: No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Rastreo de llamadas: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37811

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: ci_hdrc_imx: corrección del manejo de usbmisc. usbmisc es una propiedad opcional del dispositivo, por lo que es totalmente válido que el valor correspondiente de data->usbmisc_data sea nulo. Verifique esto antes de desreferenciar el puntero. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace.
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37812

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdns3: Corrección de interbloqueo al usar el gadget NCM. El controlador cdns3 presenta el mismo interbloqueo NCM corregido en cdnsp mediante el commit 58f2fcb3a845 ("usb: cdnsp: Corrección de un problema de interbloqueo durante el uso del gadget NCM"). Bajo PREEMPT_RT, el interbloqueo puede activarse fácilmente por tráfico de red intenso, por ejemplo, al usar "iperf --bidir" a través de un enlace Ethernet NCM. El interbloqueo se produce porque el manejador de interrupciones en subprocesos es interrumpido por un softirq, pero ambos están protegidos por el mismo bloqueo de giro. Para evitar el interbloqueo, desactive el softirq durante el controlador de interrupciones en subprocesos.
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37813

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Corregir desreferencia de puntero no válida en el workaround de Etron Esta comprobación se realiza antes de prepare_transfer() y prepare_ring(), por lo que enqueue ya puede apuntar al TRB de enlace final de un segmento. Y de hecho lo hará, alrededor del 0,4% de las veces que se llama a este código. Entonces enqueue + 1 es un puntero no válido. Hará que el kernel se caiga de inmediato o cargará algo basura que puede parecer un TRB de enlace y hacer que el TRB de enlace real se reemplace con un NOOP. Esto no terminaría bien. Utilice una prueba funcionalmente equivalente que no desreferencia el puntero y siempre dé un resultado correcto. Algo ha hecho que mi máquina se caiga dos veces en los últimos días mientras jugaba con un Etron HC, y una prueba de estrés de transferencia de control ejecutada para confirmación la acaba de hacer caer de nuevo. La misma prueba pasa con este parche aplicado.
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025

CVE-2025-37814

Fecha de publicación:
08/05/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: Requerir CAP_SYS_ADMIN para todos los usos de TIOCL_SELMOUSEREPORT Este requisito se flexibilizó con mucho entusiasmo en el commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"), pero resulta que (1) la lógica que implementé allí era inconsistente (¡disculpas!), (2) TIOCL_SELMOUSEREPORT en realidad puede ser un pequeño riesgo de seguridad después de todo, y (3) TIOCL_SELMOUSEREPORT solo está destinado a ser utilizado por el demonio del mouse (GPM o Consolation), que ya se ejecuta como CAP_SYS_ADMIN. Más detalles: 1. El parche anterior tiene una lógica inconsistente: En el commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"), verificamos que sel_mode == TIOCL_SELMOUSEREPORT, pero pasamos por alto que los cuatro bits inferiores de este parámetro "mode" se usaban como una forma adicional de pasar un argumento. Por lo tanto, el parche seguía requiriendo CAP_SYS_ADMIN si alguno de los bits del botón del ratón estaba configurado, pero no lo requería si ninguno de los bits del botón del ratón estaba configurado. Esta lógica es inconsistente y no fue intencional. Deberíamos tener las mismas políticas para usar TIOCL_SELMOUSEREPORT, independientemente del valor del argumento "oculto" del botón del ratón. Envié un parche de documentación aparte a la lista de páginas del manual con más detalles sobre TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT constituye un riesgo de seguridad potencial que puede permitir a un atacante simular la entrada de teclado en aplicaciones de línea de comandos en la misma terminal, como TIOCSTI y otras IOCTL de "modo de selección" de TIOCLINUX. Al habilitar los informes del ratón en una terminal y luego inyectarlos mediante TIOCL_SELMOUSEREPORT, un atacante puede simular los movimientos del ratón en la misma terminal, de forma similar a los ataques de inyección de pulsaciones de teclas de TIOCSTI que antes eran posibles con TIOCSTI y otros modos de selección de TIOCL_SETSEL. Muchos programas (incluidos libreadline/bash) tienden a malinterpretar estos informes del ratón como una entrada normal del teclado, ya que no esperan una entrada en el formato del protocolo X11. El atacante no tiene control total sobre la secuencia de escape, pero al menos puede controlar los valores de dos bytes consecutivos en la secuencia de escape binaria del informe del ratón. Entré en más detalles sobre eso en la discusión en https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ No es igualmente trivial simular pulsaciones de teclas arbitrarias como lo fue con TIOCSTI (commit 83efeeeb3d04 ("tty: Permitir que TIOCSTI sea deshabilitado")), pero el mecanismo general está ahí, y junto con la pequeña cantidad de casos de uso legítimos existentes (ver a continuación), sería mejor volver a requerir CAP_SYS_ADMIN para TIOCL_SELMOUSEREPORT, como ya era el caso antes del commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT solo lo utilizan los daemons de ratón (GPM o Consolation), y son el único caso de uso legítimo: Para citar console_codes(4): La función de seguimiento del ratón está diseñada para devolver informes de estado del ratón compatibles con xterm(1). Dado que el controlador de consola no puede conocer el dispositivo ni el tipo de ratón, estos informes se devuelven en el flujo de entrada de la consola solo cuando el controlador del terminal virtual recibe una instrucción ioctl de actualización del ratón. Estas instrucciones ioctl deben ser generadas por una aplicación en modo usuario que admita el ratón, como el daemon gpm(8). Jared Finder también ha confirmado en https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ que Emacs no llama a TIOCL_SELMOUSEREPORT directamente, y sería difícil encontrar buenas razones para hacerlo, dado que interferiría con los ---truncado---
Gravedad: Pendiente de análisis
Última modificación:
08/05/2025