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-64242

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 /> usb: gadget: net2280: Fix double free in probe error path<br /> <br /> usb_initialize_gadget() installs gadget_release() as the release<br /> callback for the embedded gadget device. The struct net2280 instance is<br /> therefore released through gadget_release() when the gadget device&amp;#39;s last<br /> reference is dropped.<br /> <br /> The probe error path calls net2280_remove(), which tears down the<br /> partially initialized device and drops the gadget reference with<br /> usb_put_gadget(). Calling kfree(dev) afterwards can free the same object<br /> again.<br /> <br /> Drop the explicit kfree() and let the gadget device release callback<br /> handle the final free. This issue was found by a static analysis tool<br /> I am developing.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64243

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 /> ASoC: codecs: simple-mux: Fix enum control bounds check<br /> <br /> simple_mux_control_put() rejects values greater than e-&gt;items, but<br /> enum control values are zero based. For the two-entry mux used by this<br /> driver, valid values are 0 and 1, so value 2 must be rejected as well.<br /> <br /> Accepting e-&gt;items can store an invalid mux state, pass it to the GPIO<br /> setter, and pass it on to the DAPM mux update path where it is used as<br /> an index into the enum text array.<br /> <br /> Use the same &gt;= e-&gt;items check used by the ASoC enum helpers.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64244

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 /> drivers/base/memory: set mem-&gt;altmap after successful device registration<br /> <br /> If __add_memory_block() fails at xa_store() (under memory pressure for<br /> example), device_unregister() is called, which eventually triggers<br /> memory_block_release() with mem-&gt;altmap still set, causing a<br /> WARN_ON(mem-&gt;altmap). This was triggered by modifying virtio-mem driver.<br /> <br /> Fix this by delaying the assignment of mem-&gt;altmap until after<br /> __add_memory_block() has succeeded.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64245

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 /> fbdev: modedb: fix a possible UAF in fb_find_mode()<br /> <br /> If mode_option is NULL, it is assigned from mode_option_buf:<br /> <br /> if (!mode_option) {<br /> fb_get_options(NULL, &amp;mode_option_buf);<br /> mode_option = mode_option_buf;<br /> }<br /> <br /> Later, name is assigned from mode_option:<br /> <br /> const char *name = mode_option;<br /> <br /> However, mode_option_buf is freed before name is no longer used:<br /> <br /> kfree(mode_option_buf);<br /> <br /> while name is still accessed by:<br /> <br /> if ((name_matches(db[i], name, namelen) ||<br /> <br /> Since name aliases mode_option_buf, this may result in a<br /> use-after-free.<br /> <br /> Fix this by extending the lifetime of mode_option_buf until the end of the<br /> function by using scope-based resource management for cleanup.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64229

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 /> x86/mm: Disable broadcast TLB flush when PCID is disabled<br /> <br /> Booting with "nopcid" clears X86_FEATURE_PCID and keeps CR4.PCIDE from being<br /> set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains<br /> enabled.<br /> <br /> There are two checks that decide whether the global ASID code runs,<br /> mm_global_asid() and consider_global_asid(), that key off of the<br /> X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three<br /> CPUs, consider_global_asid() assigns it a global ASID, after which<br /> flush_tlb_mm_range() takes the broadcast_tlb_flush() path using a non-zero<br /> PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set<br /> results in a #GP:<br /> <br /> Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI<br /> CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full)<br /> Hardware name: ...<br /> RIP: 0010:broadcast_tlb_flush<br /> Code: ... 89 da 48 83 c8 07 01 fe eb 08 cc cc cc ...<br /> Call Trace:<br /> <br /> flush_tlb_mm_range<br /> ptep_clear_flush<br /> wp_page_copy<br /> ? _raw_spin_unlock<br /> __handle_mm_fault<br /> handle_mm_fault<br /> do_user_addr_fault<br /> exc_page_fault<br /> asm_exc_page_fault<br /> <br /> All processors that support broadcast TLB invalidation also have PCID support,<br /> so it is only the "nopcid" scenario that is of concern. In this situation just<br /> disable the broadcast TLB support using the CPUID dependency support by making<br /> X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID.<br /> <br /> [ bp: Massage commit message. ]
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64230

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 /> regulator: tps65219: fix irq_data.rdev not being assigned<br /> <br /> Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper<br /> function") removed the tps65219_get_rdev_by_name() helper along with<br /> the irq_data.rdev assignment that depended on it. This left<br /> irq_data.rdev uninitialized for all IRQs, causing undefined behavior<br /> when regulator_notifier_call_chain() is called from the IRQ handler:<br /> <br /> Internal error: Oops: 0000000096000004<br /> pc : regulator_notifier_call_chain<br /> lr : tps65219_regulator_irq_handler<br /> Call trace:<br /> regulator_notifier_call_chain<br /> tps65219_regulator_irq_handler<br /> handle_nested_irq<br /> regmap_irq_thread<br /> irq_thread_fn<br /> irq_thread<br /> kthread<br /> ret_from_fork<br /> <br /> Instead of restoring a dedicated lookup array, restructure the probe<br /> function to combine regulator registration with IRQ registration in<br /> the same loop. This way the rdev returned by devm_regulator_register()<br /> is naturally available for assigning to irq_data.rdev without any<br /> auxiliary data structure.<br /> <br /> Non-regulator IRQs (SENSOR, TIMEOUT) that don&amp;#39;t correspond to any<br /> registered regulator are registered with rdev=NULL, and the IRQ handler<br /> is protected with a NULL check to avoid crashing.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64231

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 /> drm/msm/dsi: don&amp;#39;t dump registers past the mapped region<br /> <br /> On DSI 6G platforms the IO address space is internally adjusted by<br /> io_offset. Later this adjusted address might be used for memory dumping.<br /> However the size that is used for memory dumping isn&amp;#39;t adjusted to<br /> account for the io_offset, leading to the potential access to the<br /> unmapped region. Lower ctrl_size by the io_offset value to prevent<br /> access past the mapped area.<br /> <br /> msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P)<br /> msm_dsi_host_snapshot+0x4c/0x78 [msm]<br /> msm_dsi_snapshot+0x28/0x50 [msm]<br /> msm_disp_snapshot_capture_state+0x74/0x140 [msm]<br /> msm_disp_snapshot_state_sync+0x60/0x90 [msm]<br /> _msm_disp_snapshot_work+0x30/0x90 [msm]<br /> kthread_worker_fn+0xdc/0x460<br /> kthread+0x120/0x140<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/721747/
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64232

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 /> block: recompute nr_integrity_segments in blk_insert_cloned_request<br /> <br /> blk_insert_cloned_request() already recomputes nr_phys_segments<br /> against the bottom queue, because "the queue settings related to<br /> segment counting may differ from the original queue." The exact same<br /> reasoning applies to integrity segments: a stacked driver&amp;#39;s underlying<br /> queue can have tighter virt_boundary_mask, seg_boundary_mask, or<br /> max_segment_size than the top queue, in which case<br /> blk_rq_count_integrity_sg() against the bottom queue produces a<br /> different count than the cached rq-&gt;nr_integrity_segments inherited<br /> from the source request by blk_rq_prep_clone().<br /> <br /> When the cached count is lower than the bottom queue&amp;#39;s actual count,<br /> blk_rq_map_integrity_sg() trips<br /> <br /> BUG_ON(segments &gt; rq-&gt;nr_integrity_segments);<br /> <br /> on dispatch. The same families of stacked setups that motivated the<br /> existing nr_phys_segments recompute -- dm-multipath fanning out to<br /> nvme-rdma in particular -- can produce this.<br /> <br /> Mirror the nr_phys_segments handling: when the request carries<br /> integrity, recompute nr_integrity_segments against the bottom queue<br /> and reject the request if it exceeds the bottom queue&amp;#39;s<br /> max_integrity_segments. blk_rq_count_integrity_sg() and<br /> queue_max_integrity_segments() are both already available via<br /> , which blk-mq.c includes.<br /> <br /> This closes a latent gap in the stacking contract and brings the<br /> integrity-segment accounting in line with the existing<br /> phys-segment accounting.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64233

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 /> usb: gadget: uvc: hold opts-&gt;lock across XU walks in uvc_function_bind<br /> <br /> uvc_function_bind() walks &amp;opts-&gt;extension_units twice without holding<br /> opts-&gt;lock:<br /> <br /> - directly, for the iExtension string-descriptor fixup loop;<br /> - indirectly, four times via uvc_copy_descriptors() (once per speed),<br /> where the helper iterates uvc-&gt;desc.extension_units (which aliases<br /> &amp;opts-&gt;extension_units) to size and emit XU descriptors.<br /> <br /> The configfs side (uvcg_extension_make / uvcg_extension_drop, in<br /> drivers/usb/gadget/function/uvc_configfs.c) takes opts-&gt;lock around its<br /> list_add_tail / list_del operations. A privileged userspace process<br /> that holds the configfs subtree open and writes the gadget UDC name<br /> to bind the function while concurrently rmdir()&amp;#39;ing an extensions<br /> subdir can race uvcg_extension_drop() against the bind-time list walks<br /> and dereference a freed struct uvcg_extension.<br /> <br /> Hold opts-&gt;lock from the start of the XU string-descriptor fixup<br /> through the last uvc_copy_descriptors() call, releasing on the<br /> descriptor-error path via a new error_unlock label that drops the<br /> lock before falling through to the existing error label. This<br /> matches the locking discipline of the configfs callbacks and removes<br /> the only remaining unsynchronised reader of the XU list during bind.<br /> <br /> Reachability: only privileged processes that can mount configfs and<br /> write to gadget UDC files can trigger the race, so this is a<br /> correctness fix rather than a security boundary.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64234

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 /> tty: serial: pch_uart: add check for dma_alloc_coherent()<br /> <br /> Add a check for dma_alloc_coherent() failure to prevent a potential<br /> NULL pointer dereference in dma_handle_rx(). Properly release DMA<br /> channels and the PCI device reference using a goto ladder if the<br /> allocation fails.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64235

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 /> x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines<br /> <br /> With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected platform<br /> (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline<br /> crashes on the first call into the traced function:<br /> <br /> BUG: unable to handle page fault for address: ffff88817ae18880<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 4b53067 P4D 4b53067 PUD 0<br /> Oops: Oops: 0002 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014<br /> Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89<br /> Call Trace:<br /> <br /> ? find_held_lock<br /> ? exc_page_fault<br /> ? lock_release<br /> ? __x64_sys_clock_nanosleep<br /> ? lockdep_hardirqs_on_prepare<br /> ? trace_hardirqs_on<br /> __x64_sys_clock_nanosleep<br /> do_syscall_64<br /> ? exc_page_fault<br /> ? call_depth_return_thunk<br /> entry_SYSCALL_64_after_hwframe<br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> This small reproducer allows to easily trigger the crash:<br /> <br /> # echo &amp;#39;p __x64_sys_clock_nanosleep&amp;#39; &gt; /sys/kernel/tracing/kprobe_events<br /> # echo 1 &gt; /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable<br /> # usleep 1<br /> <br /> Monitoring the crash under GDB points to the exact instruction in charge of<br /> incrementing the call depth:<br /> <br /> sarq $5, %gs:__x86_call_depth(%rip)<br /> <br /> This instruction matches the one inserted by the ftrace_regs_caller from<br /> ftrace_64.S. This emitted code was likely working fine until the introduction<br /> of<br /> <br /> 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"):<br /> <br /> it has made the call depth accounting addressing relative to $rip, instead of<br /> being based on an absolute address.<br /> <br /> As this code exact location depends on where the trampoline lives in memory,<br /> the corresponding displacement needs to be adjusted at runtime to actually<br /> correctly find the per-cpu __x86_call_depth value, otherwise the targeted<br /> address is wrong, leading to the page fault seen above.<br /> <br /> Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT<br /> instruction (from ftrace_regs_caller) by calling text_poke_apply_relocation(),<br /> as it is done for example by the x86 BPF JIT compiler through<br /> x86_call_depth_emit_accounting(). This corrects both CALL_DEPTH_ACCOUNT slots,<br /> in ftrace_caller and ftrace_regs_caller.<br /> <br /> [ bp: Massage. ]
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026

CVE-2026-64236

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 /> i2c: davinci: fix division by zero on missing clock-frequency<br /> <br /> When the &amp;#39;clock-frequency&amp;#39; property is missing from the device tree,<br /> the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this<br /> macro was defined in kHz (100), whereas the device tree property is<br /> expected in Hz.<br /> <br /> The probe function divided the fallback value by 1000, causing<br /> integer truncation that resulted in dev-&gt;bus_freq = 0. This triggered<br /> a deterministic division-by-zero kernel panic when calculating clock<br /> dividers later in the probe sequence.<br /> <br /> Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000)<br /> to match the expected device tree property unit, allowing the existing<br /> division logic to work correctly for both cases.
Gravedad: Pendiente de análisis
Última modificación:
24/07/2026