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

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

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-46178
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()<br /> <br /> Sashiko points out that mlx4_srq_alloc() was not undone during error<br /> unwind, add the missing call to mlx4_srq_free().
Gravedad CVSS v3.1: ALTA
Última modificación:
30/05/2026

CVE-2026-46181
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()<br /> <br /> Sashiko points out the radix_tree itself is RCU safe, but nothing ever<br /> frees the mlx4_srq struct with RCU, and it isn&amp;#39;t even accessed within the<br /> RCU critical section. It also will crash if an event is delivered before<br /> the srq object is finished initializing.<br /> <br /> Use the spinlock since it isn&amp;#39;t easy to make RCU work, use<br /> refcount_inc_not_zero() to protect against partially initialized objects,<br /> and order the refcount_set() to be after the srq is fully initialized.
Gravedad CVSS v3.1: ALTA
Última modificación:
30/05/2026

CVE-2026-46165
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: vport: fix self-deadlock on release of tunnel ports<br /> <br /> vports are used concurrently and protected by RCU, so netdev_put()<br /> must happen after the RCU grace period. So, either in an RCU call or<br /> after the synchronize_net(). The rtnl_delete_link() must happen under<br /> RTNL and so can&amp;#39;t be executed in RCU context. Calling synchronize_net()<br /> while holding RTNL is not a good idea for performance and system<br /> stability under load in general, so calling netdev_put() in RCU call<br /> is the right solution here.<br /> <br /> However,<br /> when the device is deleted, rtnl_unlock() will call netdev_run_todo()<br /> and block until all the references are gone. In the current code this<br /> means that we never reach the call_rcu() and the vport is never freed<br /> and the reference is never released, causing a self-deadlock on device<br /> removal.<br /> <br /> Fix that by moving the rcu_call() before the rtnl_unlock(), so the<br /> scheduled RCU callback will be executed when synchronize_net() is<br /> called from the rtnl_unlock()-&gt;netdev_run_todo() while the RTNL itself<br /> is already released.
Gravedad: Pendiente de análisis
Última modificación:
28/05/2026

CVE-2026-46167
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl<br /> <br /> Just like in a previous problem in this driver, usblp_ctrl_msg() will<br /> collapse the usb_control_msg() return value to 0/-errno, discarding the<br /> actual number of bytes transferred.<br /> <br /> Ideally that short command should be detected and error out, but many<br /> printers are known to send "incorrect" responses back so we can&amp;#39;t just<br /> do that.<br /> <br /> statusbuf is kmalloc(8) at probe time and never filled before the first<br /> LPGETSTATUS ioctl.<br /> <br /> usblp_read_status() requests 1 byte. If a malicious printer responds<br /> with zero bytes, *statusbuf is one byte of stale kmalloc heap,<br /> sign-extended into the local int status, which the LPGETSTATUS path then<br /> copy_to_user()s directly to the ioctl caller.<br /> <br /> Fix this all by just zapping out the memory buffer when allocated at<br /> probe time. If a later call does a short read, the data will be<br /> identical to what the device sent it the last time, so there is no<br /> "leak" of information happening.
Gravedad: Pendiente de análisis
Última modificación:
28/05/2026

CVE-2026-46168
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix scheduling with atomic in timestamp sockopt<br /> <br /> Using lock_sock_fast() (atomic context) around sock_set_timestamp()<br /> and sock_set_timestamping() is unsafe, as both helpers can sleep.<br /> <br /> Replace lock_sock_fast() with sleepable lock_sock()/release_sock()<br /> to avoid scheduling while atomic panic.
Gravedad: Pendiente de análisis
Última modificación:
28/05/2026

CVE-2026-46169
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix uninit-value by validating catalog record size<br /> <br /> Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The<br /> root cause is that hfs_brec_read() doesn&amp;#39;t validate that the on-disk<br /> record size matches the expected size for the record type being read.<br /> <br /> When mounting a corrupted filesystem, hfs_brec_read() may read less data<br /> than expected. For example, when reading a catalog thread record, the<br /> debug output showed:<br /> <br /> HFSPLUS_BREC_READ: rec_len=520, fd-&gt;entrylength=26<br /> HFSPLUS_BREC_READ: WARNING - entrylength (26)
Gravedad: Pendiente de análisis
Última modificación:
28/05/2026

CVE-2026-46170
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: ADD_ADDR rtx: free sk if last<br /> <br /> When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(),<br /> and released at the end.<br /> <br /> If at that moment, it was the last reference being held, the sk would<br /> not be freed. sock_put() should then be called instead of __sock_put().<br /> <br /> But that&amp;#39;s not enough: if it is the last reference, sock_put() will call<br /> sk_free(), which will end up calling sk_stop_timer_sync() on the same<br /> timer, and waiting indefinitely to finish. So it is needed to mark that<br /> the timer is done at the end of the timer handler when it has not been<br /> rescheduled, not to call sk_stop_timer_sync() on "itself".
Gravedad: Pendiente de análisis
Última modificación:
28/05/2026

CVE-2026-46171
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: kvm: fix vector context allocation leak<br /> <br /> When the second kzalloc (host_context.vector.datap) fails in<br /> kvm_riscv_vcpu_alloc_vector_context, the first allocation<br /> (guest_context.vector.datap) is leaked. Free it before returning.
Gravedad: Pendiente de análisis
Última modificación:
28/05/2026

CVE-2026-46172
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()<br /> <br /> xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not<br /> already have a dst attached. ip6_route_input_lookup() returns a<br /> referenced dst entry even when the lookup resolves to an error route.<br /> <br /> If dst-&gt;error is set, xfrm6_rcv_encap() drops the skb without attaching<br /> the dst to the skb and without releasing the reference returned by the<br /> lookup. Repeated packets hitting this path therefore leak dst entries.<br /> <br /> Release the dst before jumping to the drop path.
Gravedad: Pendiente de análisis
Última modificación:
28/05/2026

CVE-2026-46164
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free in create_space_info_sub_group() error path<br /> <br /> When kobject_init_and_add() fails, the call chain is:<br /> <br /> create_space_info_sub_group()<br /> -&gt; btrfs_sysfs_add_space_info_type()<br /> -&gt; kobject_init_and_add()<br /> -&gt; failure<br /> -&gt; kobject_put(&amp;sub_group-&gt;kobj)<br /> -&gt; space_info_release()<br /> -&gt; kfree(sub_group)<br /> <br /> Then control returns to create_space_info_sub_group(), where:<br /> <br /> btrfs_sysfs_add_space_info_type() returns error<br /> -&gt; kfree(sub_group)<br /> <br /> Thus, sub_group is freed twice.<br /> <br /> Keep parent-&gt;sub_group[index] = NULL for the failure path, but after<br /> btrfs_sysfs_add_space_info_type() has called kobject_put(), let the<br /> kobject release callback handle the cleanup.
Gravedad CVSS v3.1: ALTA
Última modificación:
30/05/2026

CVE-2026-46166
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: use safe list iteration in radar detect work<br /> <br /> The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to<br /> be freed and removed from the list. Guard against this to avoid a<br /> slab-use-after-free error.
Gravedad CVSS v3.1: ALTA
Última modificación:
30/05/2026

CVE-2026-46173
Fecha de publicación:
28/05/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exit: prevent preemption of oopsing TASK_DEAD task<br /> <br /> When an already-exiting task oopses, make_task_dead() currently calls<br /> do_task_dead() with preemption enabled. That is forbidden:<br /> do_task_dead() calls __schedule(), which has a comment saying "WARNING:<br /> must be called with preemption disabled!".<br /> <br /> If an oopsing task is preempted in do_task_dead(), between becoming<br /> TASK_DEAD and entering the scheduler explicitly, bad things happen:<br /> finish_task_switch() assumes that once the scheduler has switched away<br /> from a TASK_DEAD task, the task can never run again and its stack is no<br /> longer needed; but that assumption apparently doesn&amp;#39;t hold if the dead<br /> task was preempted (the SM_PREEMPT case).<br /> <br /> This means that the scheduler ends up repeatedly dropping references on<br /> the dead task&amp;#39;s stack, which can lead to use-after-free or double-free<br /> of the entire task stack; in other words, two tasks can end up running<br /> on the same stack, resulting in various kinds of memory corruption.<br /> <br /> (This does not just affect "recursively oopsing" tasks; it is enough to<br /> oops once during task exit, for example in a file_operations::release<br /> handler)
Gravedad CVSS v3.1: ALTA
Última modificación:
30/05/2026
Suscribirse a Vulnerabilidades