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

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix an integer overflow in aie2_query_ctx_status_array()<br /> <br /> The unpublished smatch static checker reported a warning.<br /> <br /> drivers/accel/amdxdna/aie2_pci.c:904 aie2_query_ctx_status_array()<br /> warn: potential user controlled sizeof overflow<br /> &amp;#39;args-&gt;num_element * args-&gt;element_size&amp;#39; &amp;#39;1-u32max(user) * 1-u32max(user)&amp;#39;<br /> <br /> Even this will not cause a real issue, it is better to put a reasonable<br /> limitation for element_size and num_element. Add condition to make sure<br /> the input element_size
Gravedad: Pendiente de análisis
Última modificación:
29/12/2025

CVE-2025-68734

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()<br /> <br /> In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when<br /> setup_instance() fails with an error code. Fix that by freeing the urb<br /> before freeing the hw structure. Also change the error paths to use the<br /> goto ladder style.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool.
Gravedad: Pendiente de análisis
Última modificación:
29/12/2025

CVE-2025-68727

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: Fix uninit buffer allocated by __getname()<br /> <br /> Fix uninit errors caused after buffer allocation given to &amp;#39;de&amp;#39;; by<br /> initializing the buffer with zeroes. The fix was found by using KMSAN.
Gravedad: Pendiente de análisis
Última modificación:
19/01/2026

CVE-2025-68728

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: fix uninit memory after failed mi_read in mi_format_new<br /> <br /> Fix a KMSAN un-init bug found by syzkaller.<br /> <br /> ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be<br /> uptodate. We do not bring the buffer uptodate before setting it as<br /> uptodate. If the buffer were to not be uptodate, it could mean adding a<br /> buffer with un-init data to the mi record. Attempting to load that record<br /> will trigger KMSAN.<br /> <br /> Avoid this by setting the buffer as uptodate, if it’s not already, by<br /> overwriting it.
Gravedad: Pendiente de análisis
Última modificación:
19/01/2026

CVE-2025-68732

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpu: host1x: Fix race in syncpt alloc/free<br /> <br /> Fix race condition between host1x_syncpt_alloc()<br /> and host1x_syncpt_put() by using kref_put_mutex()<br /> instead of kref_put() + manual mutex locking.<br /> <br /> This ensures no thread can acquire the<br /> syncpt_mutex after the refcount drops to zero<br /> but before syncpt_release acquires it.<br /> This prevents races where syncpoints could<br /> be allocated while still being cleaned up<br /> from a previous release.<br /> <br /> Remove explicit mutex locking in syncpt_release<br /> as kref_put_mutex() handles this atomically.
Gravedad: Pendiente de análisis
Última modificación:
19/01/2026

CVE-2025-68733

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smack: fix bug: unprivileged task can create labels<br /> <br /> If an unprivileged task is allowed to relabel itself<br /> (/smack/relabel-self is not empty),<br /> it can freely create new labels by writing their<br /> names into own /proc/PID/attr/smack/current<br /> <br /> This occurs because do_setattr() imports<br /> the provided label in advance,<br /> before checking "relabel-self" list.<br /> <br /> This change ensures that the "relabel-self" list<br /> is checked before importing the label.
Gravedad: Pendiente de análisis
Última modificación:
19/01/2026

CVE-2025-68375

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86: Fix NULL event access and potential PEBS record loss<br /> <br /> When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the<br /> perf_event_overflow() could be called to process the last PEBS record.<br /> <br /> While perf_event_overflow() could trigger the interrupt throttle and<br /> stop all events of the group, like what the below call-chain shows.<br /> <br /> perf_event_overflow()<br /> -&gt; __perf_event_overflow()<br /> -&gt;__perf_event_account_interrupt()<br /> -&gt; perf_event_throttle_group()<br /> -&gt; perf_event_throttle()<br /> -&gt; event-&gt;pmu-&gt;stop()<br /> -&gt; x86_pmu_stop()<br /> <br /> The side effect of stopping the events is that all corresponding event<br /> pointers in cpuc-&gt;events[] array are cleared to NULL.<br /> <br /> Assume there are two PEBS events (event a and event b) in a group. When<br /> intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the<br /> last PEBS record of PEBS event a, interrupt throttle is triggered and<br /> all pointers of event a and event b are cleared to NULL. Then<br /> intel_pmu_drain_pebs_icl() tries to process the last PEBS record of<br /> event b and encounters NULL pointer access.<br /> <br /> To avoid this issue, move cpuc-&gt;events[] clearing from x86_pmu_stop()<br /> to x86_pmu_del(). It&amp;#39;s safe since cpuc-&gt;active_mask or<br /> cpuc-&gt;pebs_enabled is always checked before access the event pointer<br /> from cpuc-&gt;events[].
Gravedad: Pendiente de análisis
Última modificación:
29/12/2025

CVE-2025-68376

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: ETR: Fix ETR buffer use-after-free issue<br /> <br /> When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed<br /> and enabled again, currently sysfs_buf will point to the newly<br /> allocated memory(buf_new) and free the old memory(buf_old). But the<br /> etr_buf that is being used by the ETR remains pointed to buf_old, not<br /> updated to buf_new. In this case, it will result in a memory<br /> use-after-free issue.<br /> <br /> Fix this by checking ETR&amp;#39;s mode before updating and releasing buf_old,<br /> if the mode is CS_MODE_SYSFS, then skip updating and releasing it.
Gravedad: Pendiente de análisis
Última modificación:
29/12/2025

CVE-2025-68377

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ns: initialize ns_list_node for initial namespaces<br /> <br /> Make sure that the list is always initialized for initial namespaces.
Gravedad: Pendiente de análisis
Última modificación:
29/12/2025

CVE-2025-68378

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stackmap overflow check in __bpf_get_stackid()<br /> <br /> Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()<br /> when copying stack trace data. The issue occurs when the perf trace<br /> contains more stack entries than the stack map bucket can hold,<br /> leading to an out-of-bounds write in the bucket&amp;#39;s data array.
Gravedad: Pendiente de análisis
Última modificación:
29/12/2025

CVE-2025-68726

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: aead - Fix reqsize handling<br /> <br /> Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")<br /> introduced cra_reqsize field in crypto_alg struct to replace type<br /> specific reqsize fields. It looks like this was introduced specifically<br /> for ahash and acomp from the commit description as subsequent commits<br /> add necessary changes in these alg frameworks.<br /> <br /> However, this is being recommended for use in all crypto algs<br /> instead of setting reqsize using crypto_*_set_reqsize(). Using<br /> cra_reqsize in aead algorithms, hence, causes memory corruptions and<br /> crashes as the underlying functions in the algorithm framework have not<br /> been updated to set the reqsize properly from cra_reqsize. [1]<br /> <br /> Add proper set_reqsize calls in the aead init function to properly<br /> initialize reqsize for these algorithms in the framework.<br /> <br /> [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b
Gravedad: Pendiente de análisis
Última modificación:
29/12/2025

CVE-2025-68379

Fecha de publicación:
24/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix null deref on srq-&gt;rq.queue after resize failure<br /> <br /> A NULL pointer dereference can occur in rxe_srq_chk_attr() when<br /> ibv_modify_srq() is invoked twice in succession under certain error<br /> conditions. The first call may fail in rxe_queue_resize(), which leads<br /> rxe_srq_from_attr() to set srq-&gt;rq.queue = NULL. The second call then<br /> triggers a crash (null deref) when accessing<br /> srq-&gt;rq.queue-&gt;buf-&gt;index_mask.<br /> <br /> Call Trace:<br /> <br /> rxe_modify_srq+0x170/0x480 [rdma_rxe]<br /> ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]<br /> ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]<br /> ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]<br /> ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]<br /> ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]<br /> ? tryinc_node_nr_active+0xe6/0x150<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]<br /> ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]<br /> ? __pfx___raw_spin_lock_irqsave+0x10/0x10<br /> ? __pfx_do_vfs_ioctl+0x10/0x10<br /> ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0<br /> ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10<br /> ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]<br /> ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]<br /> __x64_sys_ioctl+0x138/0x1c0<br /> do_syscall_64+0x82/0x250<br /> ? fdget_pos+0x58/0x4c0<br /> ? ksys_write+0xf3/0x1c0<br /> ? __pfx_ksys_write+0x10/0x10<br /> ? do_syscall_64+0xc8/0x250<br /> ? __pfx_vm_mmap_pgoff+0x10/0x10<br /> ? fget+0x173/0x230<br /> ? fput+0x2a/0x80<br /> ? ksys_mmap_pgoff+0x224/0x4c0<br /> ? do_syscall_64+0xc8/0x250<br /> ? do_user_addr_fault+0x37b/0xfe0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e
Gravedad: Pendiente de análisis
Última modificación:
11/01/2026