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

Go to Calendar     Go to Press Room     Go to Newsletters subscription

Search

Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE  (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2026-23259
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rw: free potentially allocated iovec on cache put failure<br /> <br /> If a read/write request goes through io_req_rw_cleanup() and has an<br /> allocated iovec attached and fails to put to the rw_cache, then it may<br /> end up with an unaccounted iovec pointer. Have io_rw_recycle() return<br /> whether it recycled the request or not, and use that to gauge whether to<br /> free a potential iovec or not.
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23260
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: maple: free entry on mas_store_gfp() failure<br /> <br /> regcache_maple_write() allocates a new block (&amp;#39;entry&amp;#39;) to merge<br /> adjacent ranges and then stores it with mas_store_gfp().<br /> When mas_store_gfp() fails, the new &amp;#39;entry&amp;#39; remains allocated and<br /> is never freed, leaking memory.<br /> <br /> Free &amp;#39;entry&amp;#39; on the failure path; on success continue freeing the<br /> replaced neighbor blocks (&amp;#39;lower&amp;#39;, &amp;#39;upper&amp;#39;).
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23261
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fc: release admin tagset if init fails<br /> <br /> nvme_fabrics creates an NVMe/FC controller in following path:<br /> <br /> nvmf_dev_write()<br /> -&gt; nvmf_create_ctrl()<br /> -&gt; nvme_fc_create_ctrl()<br /> -&gt; nvme_fc_init_ctrl()<br /> <br /> nvme_fc_init_ctrl() allocates the admin blk-mq resources right after<br /> nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing<br /> the controller state, scheduling connect work, etc.), we jump to the<br /> fail_ctrl path, which tears down the controller references but never<br /> frees the admin queue/tag set. The leaked blk-mq allocations match the<br /> kmemleak report seen during blktests nvme/fc.<br /> <br /> Check ctrl-&gt;ctrl.admin_tagset in the fail_ctrl path and call<br /> nvme_remove_admin_tag_set() when it is set so that all admin queue<br /> allocations are reclaimed whenever controller setup aborts.
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23262
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Fix stats report corruption on queue count change<br /> <br /> The driver and the NIC share a region in memory for stats reporting.<br /> The NIC calculates its offset into this region based on the total size<br /> of the stats region and the size of the NIC&amp;#39;s stats.<br /> <br /> When the number of queues is changed, the driver&amp;#39;s stats region is<br /> resized. If the queue count is increased, the NIC can write past<br /> the end of the allocated stats region, causing memory corruption.<br /> If the queue count is decreased, there is a gap between the driver<br /> and NIC stats, leading to incorrect stats reporting.<br /> <br /> This change fixes the issue by allocating stats region with maximum<br /> size, and the offset calculation for NIC stats is changed to match<br /> with the calculation of the NIC.
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23263
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix page array leak<br /> <br /> d9f595b9a65e ("io_uring/zcrx: fix leaking pages on sg init fail") fixed<br /> a page leakage but didn&amp;#39;t free the page array, release it as well.
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23251
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: only call xf{array,blob}_destroy if we have a valid pointer<br /> <br /> Only call the xfarray and xfblob destructor if we have a valid pointer,<br /> and be sure to null out that pointer afterwards. Note that this patch<br /> fixes a large number of commits, most of which were merged between 6.9<br /> and 6.10.
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23254
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gro: fix outer network offset<br /> <br /> The udp GRO complete stage assumes that all the packets inserted the RX<br /> have the `encapsulation` flag zeroed. Such assumption is not true, as a<br /> few H/W NICs can set such flag when H/W offloading the checksum for<br /> an UDP encapsulated traffic, the tun driver can inject GSO packets with<br /> UDP encapsulation and the problematic layout can also be created via<br /> a veth based setup.<br /> <br /> Due to the above, in the problematic scenarios, udp4_gro_complete() uses<br /> the wrong network offset (inner instead of outer) to compute the outer<br /> UDP header pseudo checksum, leading to csum validation errors later on<br /> in packet processing.<br /> <br /> Address the issue always clearing the encapsulation flag at GRO completion<br /> time. Such flag will be set again as needed for encapsulated packets by<br /> udp_gro_complete().
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23256
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup<br /> <br /> In setup_nic_devices(), the initialization loop jumps to the label<br /> setup_nic_dev_free on failure. The current cleanup loop while(i--)<br /> skip the failing index i, causing a memory leak.<br /> <br /> Fix this by changing the loop to iterate from the current index i<br /> down to 0.<br /> <br /> Compile tested only. Issue found using code review.
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23257
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanup<br /> <br /> In setup_nic_devices(), the initialization loop jumps to the label<br /> setup_nic_dev_free on failure. The current cleanup loop while(i--)<br /> skip the failing index i, causing a memory leak.<br /> <br /> Fix this by changing the loop to iterate from the current index i<br /> down to 0.<br /> <br /> Also, decrement i in the devlink_alloc failure path to point to the<br /> last successfully allocated index.<br /> <br /> Compile tested only. Issue found using code review.
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2026

CVE-2026-23252
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: get rid of the xchk_xfile_*_descr calls<br /> <br /> The xchk_xfile_*_descr macros call kasprintf, which can fail to allocate<br /> memory if the formatted string is larger than 16 bytes (or whatever the<br /> nofail guarantees are nowadays). Some of them could easily exceed that,<br /> and Jiaming Zhang found a few places where that can happen with syzbot.<br /> <br /> The descriptions are debugging aids and aren&amp;#39;t required to be unique, so<br /> let&amp;#39;s just pass in static strings and eliminate this path to failure.<br /> Note this patch touches a number of commits, most of which were merged<br /> between 6.6 and 6.14.
Severity CVSS v4.0: Pending analysis
Last modification:
25/03/2026

CVE-2026-23255
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add proper RCU protection to /proc/net/ptype<br /> <br /> Yin Fengwei reported an RCU stall in ptype_seq_show() and provided<br /> a patch.<br /> <br /> Real issue is that ptype_seq_next() and ptype_seq_show() violate<br /> RCU rules.<br /> <br /> ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev<br /> to get device name without any barrier.<br /> <br /> At the same time, concurrent writers can remove a packet_type structure<br /> (which is correctly freed after an RCU grace period) and clear pt-&gt;dev<br /> without an RCU grace period.<br /> <br /> Define ptype_iter_state to carry a dev pointer along seq_net_private:<br /> <br /> struct ptype_iter_state {<br /> struct seq_net_private p;<br /> struct net_device *dev; // added in this patch<br /> };<br /> <br /> We need to record the device pointer in ptype_get_idx() and<br /> ptype_seq_next() so that ptype_seq_show() is safe against<br /> concurrent pt-&gt;dev changes.<br /> <br /> We also need to add full RCU protection in ptype_seq_next().<br /> (Missing READ_ONCE() when reading list.next values)<br /> <br /> Many thanks to Dong Chenchen for providing a repro.
Severity CVSS v4.0: Pending analysis
Last modification:
02/04/2026

CVE-2026-23253
Publication date:
18/03/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-core: fix wrong reinitialization of ringbuffer on reopen<br /> <br /> dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the<br /> DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which<br /> reinitializes the waitqueue list head to empty.<br /> <br /> Since dmxdev-&gt;dvr_buffer.queue is a shared waitqueue (all opens of the<br /> same DVR device share it), this orphans any existing waitqueue entries<br /> from io_uring poll or epoll, leaving them with stale prev/next pointers<br /> while the list head is reset to {self, self}.<br /> <br /> The waitqueue and spinlock in dvr_buffer are already properly<br /> initialized once in dvb_dmxdev_init(). The open path only needs to<br /> reset the buffer data pointer, size, and read/write positions.<br /> <br /> Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct<br /> assignment of data/size and a call to dvb_ringbuffer_reset(), which<br /> properly resets pread, pwrite, and error with correct memory ordering<br /> without touching the waitqueue or spinlock.
Severity CVSS v4.0: Pending analysis
Last modification:
02/04/2026
Subscribe to Vulnerabilities