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 últimas 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 últimas 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 últimas vulnerabilidades incorporadas al repositorio.

Vulnerabilidad en kernel de Linux (CVE-2022-49094)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrige el error de slab fuera de los límites en decrypt_internal El tamaño de memoria de tls_ctx->rx.iv para AES128-CCM es 12 configurado en tls_set_sw_offload(). El valor de retorno de crypto_aead_ivsize() para "ccm(aes)" es 16. Por lo tanto, memcpy() requiere 16 bytes de 12 bytes de espacio de memoria y activará un error de losa fuera de los límites de la siguiente manera: ========================================================================= ERROR: KASAN: losa fuera de los límites en decrypt_internal+0x385/0xc40 [tls] Lectura de tamaño 16 en la dirección ffff888114e84e60 por la tarea tls/10911 Seguimiento de llamadas: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db ? decrypt_internal+0x385/0xc40 [tls] kasan_report+0xab/0x120 ? decrypt_internal+0x385/0xc40 [tls] kasan_check_range+0xf9/0x1e0 memcpy+0x20/0x60 decrypt_internal+0x385/0xc40 [tls] ? tls_get_rec+0x2e0/0x2e0 [tls] ? process_rx_list+0x1a5/0x420 [tls] ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls] decrypt_skb_update+0x9d/0x400 [tls] tls_sw_recvmsg+0x3c8/0xb50 [tls] Asignado por la tarea 10911: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 tls_set_sw_offload+0x2eb/0xa20 [tls] tls_setsockopt+0x68c/0x700 [tls] __sys_setsockopt+0xfe/0x1b0 Reemplace crypto_aead_ivsize() con prot->iv_size + prot->salt_size cuando el valor iv de memcpy() esté en Escenario TLS_1_3_VERSION.
Gravedad CVSS v3.1: ALTA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49095)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: zorro7xx: Se corrige una pérdida de recursos en zorro7xx_remove_one() La ruta de manejo de errores de la sonda libera un recurso que no se libera en la función de eliminación. En algunos casos, se debe deshacer una operación ioremap(). Agregue la llamada iounmap() que falta en la función de eliminación.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49077)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmmremap.c: evitar invalidate_range_start/end inútil en mremap(old_size=0) Si una llamada al sistema mremap() con old_size=0 termina en move_page_tables(), llamará a invalidate_range_start()/invalidate_range_end() innecesariamente, es decir, con un rango vacío. Esto provoca una ADVERTENCIA en mmu_notifier de KVM. En el pasado, se ha diagnosticado que los rangos vacíos eran errores con un desfase de uno, de ahí la ADVERTENCIA. Dado el bajo número (hasta ahora) de informes únicos, los beneficios de detectar más llamadores con errores parecen superar el costo de tener que arreglar casos como este, donde el espacio de usuario está haciendo algo tonto. En este caso particular, un retorno temprano de move_page_tables() es suficiente para solucionar el problema.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49079)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: atravesar dispositivos bajo chunk_mutex en btrfs_can_activate_zone btrfs_can_activate_zone() se puede llamar con el device_list_mutex ya retenido, lo que provocará un bloqueo: insert_dev_extents() // Toma device_list_mutex `-> insert_dev_extent() `-> btrfs_insert_empty_item() `-> btrfs_insert_empty_items() `-> btrfs_search_slot() `-> btrfs_cow_block() `-> __btrfs_cow_block() `-> btrfs_alloc_tree_block() `-> btrfs_reserve_extent() `-> find_free_extent() `-> find_free_extent_update_loop() `-> can_allocate_chunk() `-> btrfs_can_activate_zone() // Toma device_list_mutex nuevamente En lugar de usar la RCU en fs_devices->device_list podemos usar fs_devices->alloc_list, protegido por chunk_mutex para recorrer la lista de dispositivos activos. Estamos en el hilo de asignación de fragmentos. La asignación de fragmentos más nueva ocurre desde los dispositivos en fs_device->alloc_list protegidos por chunk_mutex. btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list) Además, un dispositivo que reaparece después del montaje no se unirá a alloc_list todavía y estará en dev_list, que no queremos considerar en el contexto de la asignación de fragmentos. [15.166572] ADVERTENCIA: se detectó un posible bloqueo recursivo [15.167117] 5.17.0-rc6-dennis #79 No contaminado [15.167487] -------------------------------------------- [15.167733] kworker/u8:3/146 está intentando adquirir el bloqueo: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, en: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] pero la tarea ya tiene el bloqueo: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, en: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.167733] [15.167733] otra información que podría ayudarnos a depurar esto: [15.167733] Posible escenario de bloqueo inseguro: [15.167733] [15.171834] CPU0 [15.171834] ---- [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] [15.171834] *** BLOQUEO INTERMEDIO *** [15.171834] [15.171834] Puede deberse a la falta de notación de anidamiento de bloqueos [15.171834] [15.171834] 5 bloqueos retenidos por kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, en: process_one_work+0x1c3/0x5a0 [15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs] [15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79 [15.179641] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 01/04/2014 [15.179641] Cola de trabajo: events_unbound btrfs_async_reclaim_data_space [btrfs] [15.179641] Rastreo de llamadas: [15.179641] [15.179641] dump_stack_lvl+0x45/0x59 [15.179641] __lock_acquire.cold+0x217/0x2b2 [15.179641] lock_acquire+0xbf/0x2b0 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? lock_is_held_type+0xd7/0x130 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? _raw_spin_unlock+0x24/0x40 [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs] [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs] [15. ---truncado---
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49080)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mempolicy: arregla la fuga de mpol_new en shared_policy_replace Si mpol_new se asigna pero no se usa en el bucle de reinicio, mpol_new se liberará a través de mpol_put antes de regresar al llamador. Pero refcnt aún no se ha inicializado, por lo que mpol_put no podría hacer las cosas correctas y podría filtrar el mpol_new no utilizado. Esto sucedería si mempolicy se actualizara en el archivo shmem compartido mientras se eliminaba sp->lock durante la asignación de memoria. Este problema se podría activar fácilmente con el siguiente fragmento de código si hay muchos procesos haciendo el siguiente trabajo al mismo tiempo: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); repetir muchas veces { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49081)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: highmem: se corrigen las comprobaciones en __kmap_local_sched_{in,out}. Cuando CONFIG_DEBUG_KMAP_LOCAL está habilitado, __kmap_local_sched_{in,out} comprueba que ni siquiera las ranuras en tsk->kmap_ctrl.pteval estén asignadas. Las ranuras se inicializan con el valor 0, pero la comprobación se realiza con pte_none. Sin embargo, 0 pte no significa necesariamente que pte_none devuelva verdadero. p. ej. en xtensa devuelve falso, lo que genera las siguientes advertencias de tiempo de ejecución: ADVERTENCIA: CPU: 0 PID: 101 en mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch No contaminado 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Seguimiento de llamadas: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f ADVERTENCIA: CPU: 0 PID: 101 en mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: toque Contaminado: GW 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Seguimiento de llamadas: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 Soluciónelo reemplazando !pte_none(pteval) con pte_val(pteval) != 0.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/10/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49082)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Se corrige el use-after-free en _scsih_expander_node_remove() La función mpt3sas_transport_port_remove() llamada en _scsih_expander_node_remove() libera el campo de puerto de la estructura sas_expander, lo que lleva al siguiente splat de use-after-free de KASAN cuando se ejecuta la llamada ioc_info() después de esa función (por ejemplo, al realizar rmmod del módulo del controlador): [ 3479.371167] ===================================================================== [ 3479.378496] ERROR: KASAN: use-after-free en _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.386936] Lectura de tamaño 1 en la dirección ffff8881c037691c por la tarea rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod No contaminado 5.17.0-rc8+ #1436 [ 3479.401712] Nombre del hardware: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] [ 3479.413875] dump_stack_lvl+0x45/0x59 [ 3479.417582] print_address_description.constprop.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0xdf [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? down_write+0xde/0x150 [ 3479.470746] ? up_write+0x14d/0x460 [ 3479.475840] ? kernfs_find_ns+0x137/0x310 [ 3479.481438] pci_device_remove+0x65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_remove_driver+0xe7/0x2d0 [ 3479.504081] pci_unregister_driver+0x26/0x250 [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 [ 3479.522315] ? free_module+0xaa0/0xaa0 [ 3479.527593] ? __cond_resched+0x1c/0x90 [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 [ 3479.551828] do_syscall_64+0x35/0x80 [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ======================================================================== Solucione esto introduciendo la variable local port_id para almacenar el valor del ID del puerto antes de ejecutar mpt3sas_transport_port_remove(). Luego, esta variable local se utiliza en la llamada a ioc_info() en lugar de desreferenciar la estructura del puerto liberado.
Gravedad CVSS v3.1: ALTA
Última modificación:
25/03/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49083)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/omap: Se corrige la regresión en la sonda para la desreferencia de puntero NULL. el commit 3f6634d997db ("iommu: Use la forma correcta de recuperar iommu_ops") comenzó a activar una desreferencia de puntero NULL para algunas variantes de omap: __iommu_probe_device de probe_iommu_group+0x2c/0x38 probe_iommu_group de bus_for_each_dev+0x74/0xbc bus_for_each_dev de bus_iommu_probe+0x34/0x2e8 bus_iommu_probe de bus_set_iommu+0x80/0xc8 bus_set_iommu de omap_iommu_init+0x88/0xcc omap_iommu_init de do_one_initcall+0x44/0x24 Esto se debe a que la sonda omap iommu devuelve 0 en lugar de ERR_PTR(-ENODEV), como lo señaló Jason Gunthorpe . Parece que la regresión ya ocurrió con una confirmación anterior 6785eb9105e3 ("iommu/omap: Convertir a devoluciones de llamada de probe/release_device()") que cambió el tipo de retorno de la función y no realizó la conversión en un lugar.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49084)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: qede: confirmar que skb está asignado antes de usar qede_build_skb() supone que build_skb() siempre funciona y pasa directamente a skb_reserve(). Sin embargo, build_skb() puede fallar bajo presión de memoria. Esto da como resultado un pánico del kernel porque el skb a reservar es NULL. Agregue una verificación en caso de que build_skb() no pueda asignar y devuelva NULL. El retorno NULL se maneja correctamente en los llamadores a qede_build_skb().
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49085)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drbd: Arregla cinco errores de use-after-free en get_initial_state En get_initial_state, llama a notify_initial_state_done(skb,..) si cb->args[5]==1. Si genlmsg_put() falló en notify_initial_state_done(), el skb será liberado por nlmsg_free(skb). Entonces get_initial_state saldrá y el skb liberado será utilizado por el valor de retorno skb->len, que es un error de uaf. Lo que es peor, el mismo problema va aún más allá: skb también se puede liberar en las llamadas notify_*_state_change -> notify_*_state a continuación. Por lo tanto, ocurrieron 4 errores de uaf adicionales. Mi parche permite que las funciones llamadas al problema: notify_initial_state_done y notify_*_state_change devuelvan un código de error si ocurren errores. Para que los códigos de error se puedan propagar y los errores de uaf se puedan evitar, la v2 informa una advertencia de compilación. Esta v3 corrigió esta advertencia y se compiló correctamente en mi entorno local sin advertencias adicionales. v2: https://lore.kernel.org/patchwork/patch/1435218/
Gravedad CVSS v3.1: ALTA
Última modificación:
25/03/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49086)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: fix leak of nested shares Mientras analiza acciones proporcionadas por el usuario, el módulo openvswitch puede asignar memoria dinámicamente y almacenar punteros en la copia interna de las acciones. Por lo tanto, esta memoria debe liberarse mientras se destruyen las acciones. Actualmente solo hay dos acciones de este tipo: ct() y set(). Sin embargo, hay muchas acciones que pueden contener listas anidadas de acciones y ovs_nla_free_flow_actions() simplemente las salta, perdiendo la memoria. Por ejemplo, la eliminación del flujo con las siguientes acciones provocará una pérdida de la memoria asignada por nf_ct_tmpl_alloc(): shares:clone(ct(commit),0) La acción set() no liberada también puede perder la estructura 'dst' para la información del túnel, incluidas las referencias del dispositivo. Bajo ciertas condiciones con una alta tasa de rotación del flujo, esto puede causar un problema de pérdida de memoria significativo (2 MB por segundo en el caso del reportero). El problema también es difícil de mitigar, porque el usuario no tiene control directo sobre los flujos de rutas de datos generados por OVS. Solucione eso iterando sobre todas las acciones anidadas y liberando todo lo que se necesite liberar de forma recursiva. La nueva afirmación de tiempo de compilación debería protegernos de este problema si se agregan nuevas acciones en el futuro. Desafortunadamente, el módulo openvswitch no usa NLA_F_NESTED, por lo que todos los atributos deben verificarse explícitamente. Las acciones sample() y clone() mezclan atributos adicionales en la lista de acciones proporcionada por el usuario. Eso también evita cierta generalización del código.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/09/2025

Vulnerabilidad en kernel de Linux (CVE-2022-49078)

Fecha de publicación:
26/02/2025
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lz4: arreglar LZ4_decompress_safe_partial lectura fuera de límite Cuando se realiza una descodificación parcial, es EOF si hemos llenado el búfer de salida o no podemos continuar con la lectura de un desplazamiento para la siguiente coincidencia. En algunos casos extremos, cuando los datos comprimidos están adecuadamente dañados, se producirá UAF. Como informó KASAN [1], LZ4_decompress_safe_partial puede provocar un problema de lectura fuera de límite durante la descodificación. lz4 upstream lo ha solucionado [2] y este problema se ha discutido aquí [3] anteriormente. La rutina de descompresión actual se trasladó de lz4 v1.8.3, actualizar lib/lz4 a v1.9.+ es sin duda un gran trabajo por hacer más adelante, así que será mejor que lo solucionemos primero. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
Gravedad CVSS v3.1: ALTA
Última modificación:
19/12/2025