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.

CVE-2026-64255

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: validate sta_mask before ffs() in BA session handlers<br /> <br /> Three BA session handlers use ffs(ba_data-&gt;sta_mask) - 1 to derive a<br /> station ID without checking that sta_mask is non-zero. When sta_mask is<br /> zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing<br /> an out-of-bounds access on fw_id_to_link_sta[].<br /> <br /> Add WARN_ON_ONCE(!ba_data-&gt;sta_mask) guards before each ffs() call,<br /> consistent with the existing check in iwl_mld_ampdu_rx_start().
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64246

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init()<br /> <br /> Move of_node_put(dn) after the of_match_node() call, which still needs<br /> the node pointer. The node reference is correctly released after use.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64247

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: hyper-v: Bound the bank index when querying sparse banks<br /> <br /> When checking if a VP ID is included in a sparse bank set, explicitly check<br /> that the ID can actually be contained in a sparse bank (the TLFS allows for<br /> a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB<br /> flush for L2, the VP ID is copied verbatim from the enlightened VMCS,<br /> without any bounds check, i.e. isn&amp;#39;t guaranteed to be under the limit of<br /> 4096.<br /> <br /> Failure to check the bounds of the VP ID leads to an out-of-bounds read<br /> when testing the sparse bank, and super strictly speaking could lead to KVM<br /> performing an unnecessary TLB flush for an L2 vCPU.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm]<br /> Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802<br /> <br /> CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xcb/0x5d0<br /> kasan_report+0xb4/0xe0<br /> kasan_check_range+0x35/0x1b0<br /> hv_is_vp_in_sparse_set+0x85/0x100 [kvm]<br /> kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm]<br /> kvm_hv_hypercall+0xe6b/0x1e60 [kvm]<br /> vmx_handle_exit+0x485/0x1b60 [kvm_intel]<br /> kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm]<br /> kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0xb9/0xcf0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f0e62d1a9bf<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f<br /> flags: 0x4000000000000000(zone=1)<br /> raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> &gt;ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ^<br /> ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint<br /> <br /> Opportunistically add a compile time assertion to ensure the maximum number<br /> of sparse banks exactly matches the number of possible bits in the passed<br /> in mask.<br /> <br /> [sean: add KASAN splat, drop comment, add assert, massage changelog]
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64248

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: smp: report dying CPU to RCU in stop_this_cpu()<br /> <br /> smp_send_stop() parks all secondary CPUs in stop_this_cpu(). The function<br /> marks the CPU offline for the scheduler via set_cpu_online(false) but<br /> never informs RCU, so RCU keeps expecting a quiescent state from CPUs<br /> that are now spinning forever with interrupts disabled.<br /> <br /> As long as nothing waits for an RCU grace period after smp_send_stop()<br /> this is harmless, which is why it went unnoticed. Since commit<br /> 91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT")<br /> however, irq_work_sync() calls synchronize_rcu() on architectures without<br /> an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns<br /> false. That is the asm-generic default used by MIPS. Any irq_work_sync()<br /> issued in the reboot/shutdown path after smp_send_stop() then blocks on<br /> a grace period that can never complete, hanging the reboot:<br /> <br /> WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on<br /> ...<br /> rcu: INFO: rcu_sched detected stalls on CPUs/tasks:<br /> rcu: Offline CPU 1 blocking current GP.<br /> rcu: Offline CPU 2 blocking current GP.<br /> rcu: Offline CPU 3 blocking current GP.<br /> <br /> This issue was noticed on several Realtek MIPS switch SoCs (MIPS<br /> interAptiv) and came up during kernel bump downstream in OpenWrt from<br /> 6.18.33 to 6.18.34, after the backport of the patch to the 6.18 stable<br /> branch. The patch also has been backported all the way back to 6.1.<br /> <br /> Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring the<br /> generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs<br /> and grace periods can still complete. MIPS shuts down all CPUs here<br /> without going through the CPU-hotplug mechanism, so this report is not<br /> otherwise issued. Reporting a dying CPU to RCU outside the regular hotplug<br /> offline path is not unprecedented: arm64 does the same in cpu_die_early().<br /> There it is an exception for a CPU that was coming online and is aborting<br /> bringup, rather than the default shutdown action as on MIPS.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64249

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: region: fix use-after-free in child_regions_with_firmware()<br /> <br /> Move of_node_put(child_region) after the error print to avoid accessing<br /> freed memory when pr_err() references child_region.<br /> <br /> [ Yilun: Fix the Fixes tag ]
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64250

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Report dying CPU to RCU in stop_this_cpu()<br /> <br /> This is a port of MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying<br /> CPU to RCU in stop_this_cpu()"). smp_send_stop() parks all secondary<br /> CPUs in stop_this_cpu(). And the function marks the CPU offline for the<br /> scheduler via set_cpu_online(false) but never informs RCU, so RCU keeps<br /> expecting a quiescent state from CPUs that are now spinning forever with<br /> interrupts disabled.<br /> <br /> As long as nothing waits for an RCU grace period after smp_send_stop()<br /> this is harmless, which is why it went unnoticed. However, since commit<br /> 91840be8f710370 ("irq_work: Fix use-after-free in irq_work_single() on<br /> PREEMPT_RT"), irq_work_sync() calls synchronize_rcu() on architectures<br /> without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt()<br /> returns false. Any irq_work_sync() issued in the reboot/shutdown/halt<br /> path after smp_send_stop() then blocks on a grace period that can never<br /> complete, hanging the reboot:<br /> <br /> WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on<br /> ...<br /> rcu: INFO: rcu_sched detected stalls on CPUs/tasks:<br /> rcu: Offline CPU 1 blocking current GP.<br /> rcu: Offline CPU 2 blocking current GP.<br /> rcu: Offline CPU 3 blocking current GP.<br /> <br /> This issue needs some hacks to reproduce, and it was not noticed on<br /> LoongArch because arch_irq_work_has_interrupt() usually returns true.<br /> <br /> Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring<br /> the generic CPU-hotplug offline path, so RCU stops waiting on the parked<br /> CPUs and grace periods can still complete. LoongArch shuts down all CPUs<br /> here without going through the CPU-hotplug mechanism, so this report is<br /> not otherwise issued.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64251

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next()<br /> <br /> pwrseq_debugfs_seq_next() declares &amp;#39;next&amp;#39; with __free(put_device),<br /> which causes put_device() to be called on the returned pointer when<br /> the variable goes out of scope. This results in a use-after-free<br /> since the seq_file framework receives a pointer whose reference has<br /> already been dropped.<br /> <br /> Simply removing __free(put_device) would fix the UAF but would leak<br /> the reference acquired by bus_find_next_device(), as stop() only<br /> calls up_read(&amp;pwrseq_sem) and never releases the device reference.<br /> <br /> Fix this by making the reference counting consistent across all<br /> seq_file callbacks, matching the standard pattern used by PCI and<br /> SCSI:<br /> <br /> - start(): use get_device() so it returns a referenced pointer.<br /> - next(): explicitly put_device(curr) to release the previous<br /> device&amp;#39;s reference (no NULL check needed - the seq_file framework<br /> only calls next() while the previous return was non-NULL).<br /> - stop(): put_device(data) to release the last iterated device&amp;#39;s<br /> reference, with a NULL guard since stop() may be called with NULL<br /> when start() returned NULL or next() reached end-of-sequence.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64252

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: DEC: Prevent initial console buffer from landing in XKPHYS<br /> <br /> In 64-bit configurations calling the initial console output handler from<br /> a kernel thread other than the initial one will result in a situation<br /> where the stack has been placed in the XKPHYS 64-bit memory segment and<br /> consequently so has been the buffer allocated there that is used as the<br /> argument corresponding to the `%s&amp;#39; output conversion specifier for the<br /> firmware&amp;#39;s printf() entry point.<br /> <br /> This 64-bit address will then be truncated by 32-bit firmware, resulting<br /> in an attempt to access the wrong memory location, which in turn will<br /> cause all kinds of unpredictable behaviour, such as a kernel crash:<br /> <br /> Console: colour dummy device 160x64<br /> Calibrating delay loop... 49.36 BogoMIPS (lpj=192512)<br /> pid_max: default: 32768 minimum: 301<br /> CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800<br /> Oops[#1]:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121<br /> $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0<br /> $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073<br /> $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473<br /> $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000<br /> $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240<br /> $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b<br /> $24 : ffffffffffffffbf 000000000203bd00<br /> $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800<br /> Hi : 0000000000000000<br /> Lo : 0000000000000aa8<br /> epc : ffffffffbfc08364 0xffffffffbfc08364<br /> ra : ffffffffbfc08800 0xffffffffbfc08800<br /> Status: 140120e2 KX SX UX KERNEL EXL<br /> Cause : 00000008 (ExcCode 02)<br /> BadVA : 000000000203bd00<br /> PrId : 00000430 (R4000SC)<br /> Modules linked in:<br /> Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)<br /> Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d<br /> 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38<br /> 0000000000000000 000000000203bd00 0000000000000000 0000000000000000<br /> 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000<br /> 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172<br /> 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320<br /> 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000<br /> ...<br /> Call Trace:<br /> <br /> Code: a082ffff 03e00008 00601021 00001821 10400005 24840001 80820000 24630001<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8)<br /> &gt;&gt;<br /> <br /> In this case the pointer in $4 was truncated from 0x980000000203bd00 to<br /> 0x000000000203bd00.<br /> <br /> This may happen when no final console driver has been enabled in the<br /> configuration and consequently the initial console continues being used<br /> late into bootstrap or with an upcoming change that will switch the zs<br /> driver to use a platform device, which in turn will make the console<br /> handover happen only after other kernel threads have already been<br /> started.<br /> <br /> Fix the issue by making the buffer static and initdata, and therefore<br /> placed in the CKSEG0 32-bit compatibility segment, observing that the<br /> console output handler is called with the console lock held, implying<br /> no need for this code to be reentrant. Add an assertion to verify the<br /> buffer actually has been placed in a compatibility segment.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64238

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: shared: fix deadlock on shared proxy&amp;#39;s parent removal<br /> <br /> Commit 710abda58055 ("gpio: shared: call gpio_chip::of_xlate() if set")<br /> used the mutex embedded in struct gpio_shared_entry to protect the<br /> offset field which now can be modified after assignment. The critical<br /> section however is too wide and introduced a potential deadlock on the<br /> removal of the shared GPIO proxy&amp;#39;s parent.<br /> <br /> Make the critical section shorter - only protect the offset when it&amp;#39;s<br /> being read.<br /> <br /> While at it: mention the fact that the entry lock is now also used to<br /> protect against concurrent access to the offset field in the structure&amp;#39;s<br /> documentation.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64239

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()<br /> <br /> DAMON sysfs maintains the DAMOS tried region directory objects via a<br /> linked list. When the user requests refresh of the directories, DAMON<br /> sysfs removes all the region directories first, and then generate updated<br /> regions directory on the empty space. The removal function<br /> (damon_sysfs_scheme_regions_rm_dirs()) only puts the kobj objects. <br /> Deletion of the container region object from the linked list is done<br /> inside the kobj release callback function.<br /> <br /> If somehow the callback invocation is delayed, the list will contain<br /> regions list that gonna be freed. If the updated region directories<br /> creation is started in this situation, the list can be corrupted and<br /> use-after-free can happen.<br /> <br /> Because the kobj objects are managed by only DAMON sysfs, the issue cannot<br /> happen in normal situation. But, such delays can be made on kernels that<br /> built with CONFIG_DEBUG_KOBJECT_RELEASE. On the kernel, the issue can<br /> indeed be reproduced like below.<br /> <br /> # damo start --damos_action stat<br /> # cd /sys/kernel/mm/damon/admin/kdamonds/0/<br /> # for i in {1..10}; do echo update_schemes_tried_regions &gt; state; done<br /> # dmesg | grep underflow<br /> [ 89.296152] refcount_t: underflow; use-after-free.<br /> <br /> Fix the issue by removing the region object from the list when<br /> decrementing the reference count.<br /> <br /> Also update damos_sysfs_populate_region_dir() to add the region object to<br /> the list only after the kobject_init_and_add() is success, so that fail of<br /> kobject_init_and_add() is not leaving the deallocated object on the list.<br /> <br /> The issue was discovered [1] by Sashiko.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64240

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rc: igorplugusb: fix control request setup packet<br /> <br /> Commit eac69475b01f ("media: rc: igorplugusb: heed coherency<br /> rules") changed the control request storage from an embedded struct to<br /> an allocated pointer so it can obey DMA coherency rules.<br /> <br /> However, the driver still passes &amp;ir-&gt;request to usb_fill_control_urb().<br /> That points the URB setup packet at the pointer field itself rather than<br /> at the allocated struct usb_ctrlrequest.<br /> <br /> USB core then interprets pointer bytes as the setup packet. This can<br /> produce an invalid bRequestType and trigger the control direction warning<br /> reported by syzbot:<br /> <br /> usb 2-1: BOGUS control dir, pipe 80003580 doesn&amp;#39;t match bRequestType 0<br /> <br /> Pass ir-&gt;request itself as the setup packet.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64241

Fecha de publicación:
24/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: rockchip: teardown bugs and resource leaks<br /> <br /> Address several teardown issues and resource leaks in the driver&amp;#39;s remove<br /> path and error handling:<br /> <br /> 1. Debounce clock reference leak: The debounce clock (bank-&gt;db_clk) is<br /> obtained using of_clk_get() which increments the clock&amp;#39;s reference<br /> count, but clk_put() is never called. Register a devm action to<br /> cleanly release it on unbind. Note that of_clk_get(..., 1) remains<br /> necessary over devm_clk_get() because the DT binding does not define<br /> clock-names, precluding name-based lookup.<br /> <br /> 2. Unregistered chained IRQ handler: The chained IRQ handler is not<br /> disconnected in remove(). If a stray interrupt fires after the driver<br /> is removed, the kernel attempts to execute a stale handler, leading<br /> to a panic. Fix this by clearing the handler in remove().<br /> <br /> 3. IRQ domain leak: The linear IRQ domain and its generic chips are<br /> allocated manually during probe but never removed. Remove the IRQ<br /> domain during driver teardown to free the associated generic chips<br /> and mappings.<br /> <br /> [Bartosz: don&amp;#39;t emit an error message on devres allocation failure]
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026