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-2025-68362
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 /> wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()<br /> <br /> The rtl8187_rx_cb() calculates the rx descriptor header address<br /> by subtracting its size from the skb tail pointer.<br /> However, it does not validate if the received packet<br /> (skb-&gt;len from urb-&gt;actual_length) is large enough to contain this<br /> header.<br /> <br /> If a truncated packet is received, this will lead to a buffer<br /> underflow, reading memory before the start of the skb data area,<br /> and causing a kernel panic.<br /> <br /> Add length checks for both rtl8187 and rtl8187b descriptor headers<br /> before attempting to access them, dropping the packet cleanly if the<br /> check fails.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68363
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: Check skb-&gt;transport_header is set in bpf_skb_check_mtu<br /> <br /> The bpf_skb_check_mtu helper needs to use skb-&gt;transport_header when<br /> the BPF_MTU_CHK_SEGS flag is used:<br /> <br /> bpf_skb_check_mtu(skb, ifindex, &amp;mtu_len, 0, BPF_MTU_CHK_SEGS)<br /> <br /> The transport_header is not always set. There is a WARN_ON_ONCE<br /> report when CONFIG_DEBUG_NET is enabled + skb-&gt;gso_size is set +<br /> bpf_prog_test_run is used:<br /> <br /> WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071<br /> skb_gso_validate_network_len<br /> bpf_skb_check_mtu<br /> bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch<br /> bpf_test_run<br /> bpf_prog_test_run_skb<br /> <br /> For a normal ingress skb (not test_run), skb_reset_transport_header<br /> is performed but there is plan to avoid setting it as described in<br /> commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").<br /> <br /> This patch fixes the bpf helper by checking<br /> skb_transport_header_was_set(). The check is done just before<br /> skb-&gt;transport_header is used, to avoid breaking the existing bpf prog.<br /> The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68364
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 /> ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()<br /> <br /> In &amp;#39;__ocfs2_move_extent()&amp;#39;, relax &amp;#39;BUG()&amp;#39; to &amp;#39;ocfs2_error()&amp;#39; just<br /> to avoid crashing the whole kernel due to a filesystem corruption.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68351
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 /> exfat: fix refcount leak in exfat_find<br /> <br /> Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.<br /> <br /> Function `exfat_get_dentry_set` would increase the reference counter of<br /> `es-&gt;bh` on success. Therefore, `exfat_put_dentry_set` must be called<br /> after `exfat_get_dentry_set` to ensure refcount consistency. This patch<br /> relocate two checks to avoid possible leaks.
Gravedad CVSS v3.1: MEDIA
Última modificación:
26/02/2026

CVE-2025-68347
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 /> ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events<br /> <br /> The DSP event handling code in hwdep_read() could write more bytes to<br /> the user buffer than requested, when a user provides a buffer smaller<br /> than the event header size (8 bytes).<br /> <br /> Fix by using min_t() to clamp the copy size, This ensures we never copy<br /> more than the user requested.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68348
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 /> block: fix memory leak in __blkdev_issue_zero_pages<br /> <br /> Move the fatal signal check before bio_alloc() to prevent a memory<br /> leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending.<br /> <br /> Previously, the bio was allocated before checking for a fatal signal.<br /> If a signal was pending, the code would break out of the loop without<br /> freeing or chaining the just-allocated bio, causing a memory leak.<br /> <br /> This matches the pattern already used in __blkdev_issue_write_zeroes()<br /> where the signal check precedes the allocation.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68349
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 /> NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid<br /> <br /> Fixes a crash when layout is null during this call stack:<br /> <br /> write_inode<br /> -&gt; nfs4_write_inode<br /> -&gt; pnfs_layoutcommit_inode<br /> <br /> pnfs_set_layoutcommit relies on the lseg refcount to keep the layout<br /> around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt<br /> to reference a null layout.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68350
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 /> exfat: fix divide-by-zero in exfat_allocate_bitmap<br /> <br /> The variable max_ra_count can be 0 in exfat_allocate_bitmap(),<br /> which causes a divide-by-zero error in the subsequent modulo operation<br /> (i % max_ra_count), leading to a system crash.<br /> When max_ra_count is 0, it means that readahead is not used. This patch<br /> load the bitmap without readahead.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68352
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 /> spi: ch341: fix out-of-bounds memory access in ch341_transfer_one<br /> <br /> Discovered by Atuin - Automated Vulnerability Discovery Engine.<br /> <br /> The &amp;#39;len&amp;#39; variable is calculated as &amp;#39;min(32, trans-&gt;len + 1)&amp;#39;,<br /> which includes the 1-byte command header.<br /> <br /> When copying data from &amp;#39;trans-&gt;tx_buf&amp;#39; to &amp;#39;ch341-&gt;tx_buf + 1&amp;#39;, using &amp;#39;len&amp;#39;<br /> as the length is incorrect because:<br /> <br /> 1. It causes an out-of-bounds read from &amp;#39;trans-&gt;tx_buf&amp;#39; (which has size<br /> &amp;#39;trans-&gt;len&amp;#39;, i.e., &amp;#39;len - 1&amp;#39; in this context).<br /> 2. It can cause an out-of-bounds write to &amp;#39;ch341-&gt;tx_buf&amp;#39; if &amp;#39;len&amp;#39; is<br /> CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341-&gt;tx_buf + 1<br /> overflows the buffer.<br /> <br /> Fix this by copying &amp;#39;len - 1&amp;#39; bytes.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68353
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 /> net: vxlan: prevent NULL deref in vxlan_xmit_one<br /> <br /> Neither sock4 nor sock6 pointers are guaranteed to be non-NULL in<br /> vxlan_xmit_one, e.g. if the iface is brought down. This can lead to the<br /> following NULL dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:vxlan_xmit_one+0xbb3/0x1580<br /> Call Trace:<br /> vxlan_xmit+0x429/0x610<br /> dev_hard_start_xmit+0x55/0xa0<br /> __dev_queue_xmit+0x6d0/0x7f0<br /> ip_finish_output2+0x24b/0x590<br /> ip_output+0x63/0x110<br /> <br /> Mentioned commits changed the code path in vxlan_xmit_one and as a side<br /> effect the sock4/6 pointer validity checks in vxlan(6)_get_route were<br /> lost. Fix this by adding back checks.<br /> <br /> Since both commits being fixed were released in the same version (v6.7)<br /> and are strongly related, bundle the fixes in a single commit.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68354
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 /> regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex<br /> <br /> regulator_supply_alias_list was accessed without any locking in<br /> regulator_supply_alias(), regulator_register_supply_alias(), and<br /> regulator_unregister_supply_alias(). Concurrent registration,<br /> unregistration and lookups can race, leading to:<br /> <br /> 1 use-after-free if an alias entry is removed while being read,<br /> 2 duplicate entries when two threads register the same alias,<br /> 3 inconsistent alias mappings observed by consumers.<br /> <br /> Protect all traversals, insertions and deletions on<br /> regulator_supply_alias_list with the existing regulator_list_mutex.
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026

CVE-2025-68355
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 exclusive map memory leak<br /> <br /> When excl_prog_hash is 0 and excl_prog_hash_size is non-zero, the map also<br /> needs to be freed. Otherwise, the map memory will not be reclaimed, just<br /> like the memory leak problem reported by syzbot [1].<br /> <br /> syzbot reported:<br /> BUG: memory leak<br /> backtrace (crc 7b9fb9b4):<br /> map_create+0x322/0x11e0 kernel/bpf/syscall.c:1512<br /> __sys_bpf+0x3556/0x3610 kernel/bpf/syscall.c:6131
Gravedad: Pendiente de análisis
Última modificación:
15/04/2026
Suscribirse a Vulnerabilidades