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-2026-23070

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Octeontx2-af: Add proper checks for fwdata<br /> <br /> firmware populates MAC address, link modes (supported, advertised)<br /> and EEPROM data in shared firmware structure which kernel access<br /> via MAC block(CGX/RPM).<br /> <br /> Accessing fwdata, on boards booted with out MAC block leading to<br /> kernel panics.<br /> <br /> Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 10.460721] Modules linked in:<br /> [ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT<br /> [ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)<br /> [ 10.479793] Workqueue: events work_for_cpu_fn<br /> [ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 10.491124] pc : rvu_sdp_init+0x18/0x114<br /> [ 10.495051] lr : rvu_probe+0xe58/0x1d18
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23071

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: Fix race condition in hwspinlock irqsave routine<br /> <br /> Previously, the address of the shared member &amp;#39;&amp;map-&gt;spinlock_flags&amp;#39; was<br /> passed directly to &amp;#39;hwspin_lock_timeout_irqsave&amp;#39;. This creates a race<br /> condition where multiple contexts contending for the lock could overwrite<br /> the shared flags variable, potentially corrupting the state for the<br /> current lock owner.<br /> <br /> Fix this by using a local stack variable &amp;#39;flags&amp;#39; to store the IRQ state<br /> temporarily.
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23072

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: Fix memleak in l2tp_udp_encap_recv().<br /> <br /> syzbot reported memleak of struct l2tp_session, l2tp_tunnel,<br /> sock, etc. [0]<br /> <br /> The cited commit moved down the validation of the protocol<br /> version in l2tp_udp_encap_recv().<br /> <br /> The new place requires an extra error handling to avoid the<br /> memleak.<br /> <br /> Let&amp;#39;s call l2tp_session_put() there.<br /> <br /> [0]:<br /> BUG: memory leak<br /> unreferenced object 0xffff88810a290200 (size 512):<br /> comm "syz.0.17", pid 6086, jiffies 4294944299<br /> hex dump (first 32 bytes):<br /> 7d eb 04 0c 00 00 00 00 01 00 00 00 00 00 00 00 }...............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc babb6a4f):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> __do_kmalloc_node mm/slub.c:5656 [inline]<br /> __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c:1778<br /> pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755<br /> __sys_connect_file+0x7a/0xb0 net/socket.c:2089<br /> __sys_connect+0xde/0x110 net/socket.c:2108<br /> __do_sys_connect net/socket.c:2114 [inline]<br /> __se_sys_connect net/socket.c:2111 [inline]<br /> __x64_sys_connect+0x1c/0x30 net/socket.c:2111<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23054

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hv_netvsc: reject RSS hash key programming without RX indirection table<br /> <br /> RSS configuration requires a valid RX indirection table. When the device<br /> reports a single receive queue, rndis_filter_device_add() does not<br /> allocate an indirection table, accepting RSS hash key updates in this<br /> state leads to a hang.<br /> <br /> Fix this by gating netvsc_set_rxfh() on ndc-&gt;rx_table_sz and return<br /> -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device<br /> capabilities and prevents incorrect behavior.
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23055

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: riic: Move suspend handling to NOIRQ phase<br /> <br /> Commit 53326135d0e0 ("i2c: riic: Add suspend/resume support") added<br /> suspend support for the Renesas I2C driver and following this change<br /> on RZ/G3E the following WARNING is seen on entering suspend ...<br /> <br /> [ 134.275704] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)<br /> [ 134.285536] ------------[ cut here ]------------<br /> [ 134.290298] i2c i2c-2: Transfer while suspended<br /> [ 134.295174] WARNING: drivers/i2c/i2c-core.h:56 at __i2c_smbus_xfer+0x1e4/0x214, CPU#0: systemd-sleep/388<br /> [ 134.365507] Tainted: [W]=WARN<br /> [ 134.368485] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT)<br /> [ 134.375961] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 134.382935] pc : __i2c_smbus_xfer+0x1e4/0x214<br /> [ 134.387329] lr : __i2c_smbus_xfer+0x1e4/0x214<br /> [ 134.391717] sp : ffff800083f23860<br /> [ 134.395040] x29: ffff800083f23860 x28: 0000000000000000 x27: ffff800082ed5d60<br /> [ 134.402226] x26: 0000001f4395fd74 x25: 0000000000000007 x24: 0000000000000001<br /> [ 134.409408] x23: 0000000000000000 x22: 000000000000006f x21: ffff800083f23936<br /> [ 134.416589] x20: ffff0000c090e140 x19: ffff0000c090e0d0 x18: 0000000000000006<br /> [ 134.423771] x17: 6f63657320313030 x16: 2e30206465737061 x15: ffff800083f23280<br /> [ 134.430953] x14: 0000000000000000 x13: ffff800082b16ce8 x12: 0000000000000f09<br /> [ 134.438134] x11: 0000000000000503 x10: ffff800082b6ece8 x9 : ffff800082b16ce8<br /> [ 134.445315] x8 : 00000000ffffefff x7 : ffff800082b6ece8 x6 : 80000000fffff000<br /> [ 134.452495] x5 : 0000000000000504 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 134.459672] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c9ee9e80<br /> [ 134.466851] Call trace:<br /> [ 134.469311] __i2c_smbus_xfer+0x1e4/0x214 (P)<br /> [ 134.473715] i2c_smbus_xfer+0xbc/0x120<br /> [ 134.477507] i2c_smbus_read_byte_data+0x4c/0x84<br /> [ 134.482077] isl1208_i2c_read_time+0x44/0x178 [rtc_isl1208]<br /> [ 134.487703] isl1208_rtc_read_time+0x14/0x20 [rtc_isl1208]<br /> [ 134.493226] __rtc_read_time+0x44/0x88<br /> [ 134.497012] rtc_read_time+0x3c/0x68<br /> [ 134.500622] rtc_suspend+0x9c/0x170<br /> <br /> The warning is triggered because I2C transfers can still be attempted<br /> while the controller is already suspended, due to inappropriate ordering<br /> of the system sleep callbacks.<br /> <br /> If the controller is autosuspended, there is no way to wake it up once<br /> runtime PM disabled (in suspend_late()). During system resume, the I2C<br /> controller will be available only after runtime PM is re-enabled<br /> (in resume_early()). However, this may be too late for some devices.<br /> <br /> Wake up the controller in the suspend() callback while runtime PM is<br /> still enabled. The I2C controller will remain available until the<br /> suspend_noirq() callback (pm_runtime_force_suspend()) is called. During<br /> resume, the I2C controller can be restored by the resume_noirq() callback<br /> (pm_runtime_force_resume()). Finally, the resume() callback re-enables<br /> autosuspend. As a result, the I2C controller can remain available until<br /> the system enters suspend_noirq() and from resume_noirq().
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23056

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: implement mremap in uacce_vm_ops to return -EPERM<br /> <br /> The current uacce_vm_ops does not support the mremap operation of<br /> vm_operations_struct. Implement .mremap to return -EPERM to remind<br /> users.<br /> <br /> The reason we need to explicitly disable mremap is that when the<br /> driver does not implement .mremap, it uses the default mremap<br /> method. This could lead to a risk scenario:<br /> <br /> An application might first mmap address p1, then mremap to p2,<br /> followed by munmap(p1), and finally munmap(p2). Since the default<br /> mremap copies the original vma&amp;#39;s vm_private_data (i.e., q) to the<br /> new vma, both munmap operations would trigger vma_close, causing<br /> q-&gt;qfr to be freed twice(qfr will be set to null here, so repeated<br /> release is ok).
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23057

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: Coalesce only linear skb<br /> <br /> vsock/virtio common tries to coalesce buffers in rx queue: if a linear skb<br /> (with a spare tail room) is followed by a small skb (length limited by<br /> GOOD_COPY_LEN = 128), an attempt is made to join them.<br /> <br /> Since the introduction of MSG_ZEROCOPY support, assumption that a small skb<br /> will always be linear is incorrect. In the zerocopy case, data is lost and<br /> the linear skb is appended with uninitialized kernel memory.<br /> <br /> Of all 3 supported virtio-based transports, only loopback-transport is<br /> affected. G2H virtio-transport rx queue operates on explicitly linear skbs;<br /> see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2G<br /> vhost-transport may allocate non-linear skbs, but only for sizes that are<br /> not considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER in<br /> virtio_vsock_alloc_skb().<br /> <br /> Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) &gt; 0<br /> guarantees last_skb is linear.
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23058

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In ems_usb_open(), the URBs for USB-in transfers are allocated, added to<br /> the dev-&gt;rx_submitted anchor and submitted. In the complete callback<br /> ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In<br /> ems_usb_close() the URBs are freed by calling<br /> usb_kill_anchored_urbs(&amp;dev-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in ems_usb_close().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> ems_usb_read_bulk_callback() to the dev-&gt;rx_submitted anchor.
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23059

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Sanitize payload size to prevent member overflow<br /> <br /> In qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_size<br /> reported by firmware is used to calculate the copy length into<br /> item-&gt;iocb. However, the iocb member is defined as a fixed-size 64-byte<br /> array within struct purex_item.<br /> <br /> If the reported frame_size exceeds 64 bytes, subsequent memcpy calls will<br /> overflow the iocb member boundary. While extra memory might be allocated,<br /> this cross-member write is unsafe and triggers warnings under<br /> CONFIG_FORTIFY_SOURCE.<br /> <br /> Fix this by capping total_bytes to the size of the iocb member (64 bytes)<br /> before allocation and copying. This ensures all copies remain within the<br /> bounds of the destination structure member.
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23060

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: authencesn - reject too-short AAD (assoclen
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23061

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In kvaser_usb_set_{,data_}bittiming() -&gt; kvaser_usb_setup_rx_urbs(), the<br /> URBs for USB-in transfers are allocated, added to the dev-&gt;rx_submitted<br /> anchor and submitted. In the complete callback<br /> kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In<br /> kvaser_usb_remove_interfaces() the URBs are freed by calling<br /> usb_kill_anchored_urbs(&amp;dev-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in usb_kill_anchored_urbs().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> kvaser_usb_read_bulk_callback() to the dev-&gt;rx_submitted anchor.
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026

CVE-2026-23062

Fecha de publicación:
04/02/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro<br /> <br /> The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs<br /> attributes:<br /> <br /> 1. Off-by-one error: The loop condition used &amp;#39;
Gravedad: Pendiente de análisis
Última modificación:
04/02/2026