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-31639
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix key reference count leak from call-&gt;key<br /> <br /> When creating a client call in rxrpc_alloc_client_call(), the code obtains<br /> a reference to the key. This is never cleaned up and gets leaked when the<br /> call is destroyed.<br /> <br /> Fix this by freeing call-&gt;key in rxrpc_destroy_call().<br /> <br /> Before the patch, it shows the key reference counter elevated:<br /> <br /> $ cat /proc/keys | grep afs@54321<br /> 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka<br /> $<br /> <br /> After the patch, the invalidated key is removed when the code exits:<br /> <br /> $ cat /proc/keys | grep afs@54321<br /> $
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31640
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix use of wrong skb when comparing queued RESP challenge serial<br /> <br /> In rxrpc_post_response(), the code should be comparing the challenge serial<br /> number from the cached response before deciding to switch to a newer<br /> response, but looks at the newer packet private data instead, rendering the<br /> comparison always false.<br /> <br /> Fix this by switching to look at the older packet.<br /> <br /> Fix further[1] to substitute the new packet in place of the old one if<br /> newer and also to release whichever we don&amp;#39;t use.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31641
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix RxGK token loading to check bounds<br /> <br /> rxrpc_preparse_xdr_yfs_rxgk() reads the raw key length and ticket length<br /> from the XDR token as u32 values and passes each through round_up(x, 4)<br /> before using the rounded value for validation and allocation. When the raw<br /> length is &gt;= 0xfffffffd, round_up() wraps to 0, so the bounds check and<br /> kzalloc both use 0 while the subsequent memcpy still copies the original<br /> ~4 GiB value, producing a heap buffer overflow reachable from an<br /> unprivileged add_key() call.<br /> <br /> Fix this by:<br /> <br /> (1) Rejecting raw key lengths above AFSTOKEN_GK_KEY_MAX and raw ticket<br /> lengths above AFSTOKEN_GK_TOKEN_MAX before rounding, consistent with<br /> the caps that the RxKAD path already enforces via AFSTOKEN_RK_TIX_MAX.<br /> <br /> (2) Sizing the flexible-array allocation from the validated raw key<br /> length via struct_size_t() instead of the rounded value.<br /> <br /> (3) Caching the raw lengths so that the later field assignments and<br /> memcpy calls do not re-read from the token, eliminating a class of<br /> TOCTOU re-parse.<br /> <br /> The control path (valid token with lengths within bounds) is unaffected.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31642
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix call removal to use RCU safe deletion<br /> <br /> Fix rxrpc call removal from the rxnet-&gt;calls list to use list_del_rcu()<br /> rather than list_del_init() to prevent stuffing up reading<br /> /proc/net/rxrpc/calls from potentially getting into an infinite loop.<br /> <br /> This, however, means that list_empty() no longer works on an entry that&amp;#39;s<br /> been deleted from the list, making it harder to detect prior deletion. Fix<br /> this by:<br /> <br /> Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that<br /> are unexpectedly still on the list. Limiting the number of steps means<br /> there&amp;#39;s no need to call cond_resched() or to remove calls from the list<br /> here, thereby eliminating the need for rxrpc_put_call() to check for that.<br /> <br /> rxrpc_put_call() can then be fixed to unconditionally delete the call from<br /> the list as it is the only place that the deletion occurs.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31643
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix key parsing memleak<br /> <br /> In rxrpc_preparse_xdr_yfs_rxgk(), the memory attached to token-&gt;rxgk can be<br /> leaked in a few error paths after it&amp;#39;s allocated.<br /> <br /> Fix this by freeing it in the "reject_token:" case.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31644
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan966x: fix use-after-free and leak in lan966x_fdma_reload()<br /> <br /> When lan966x_fdma_reload() fails to allocate new RX buffers, the restore<br /> path restarts DMA using old descriptors whose pages were already freed<br /> via lan966x_fdma_rx_free_pages(). Since page_pool_put_full_page() can<br /> release pages back to the buddy allocator, the hardware may DMA into<br /> memory now owned by other kernel subsystems.<br /> <br /> Additionally, on the restore path, the newly created page pool (if<br /> allocation partially succeeded) is overwritten without being destroyed,<br /> leaking it.<br /> <br /> Fix both issues by deferring the release of old pages until after the<br /> new allocation succeeds. Save the old page array before the allocation<br /> so old pages can be freed on the success path. On the failure path, the<br /> old descriptors, pages and page pool are all still valid, making the<br /> restore safe. Also ensure the restore path re-enables NAPI and wakes<br /> the netdev, matching the success path.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31645
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan966x: fix page pool leak in error paths<br /> <br /> lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if<br /> the subsequent fdma_alloc_coherent() call fails, leaking the pool.<br /> <br /> Similarly, lan966x_fdma_init() frees the coherent DMA memory when<br /> lan966x_fdma_tx_alloc() fails but does not destroy the page pool that<br /> was successfully created by lan966x_fdma_rx_alloc(), leaking it.<br /> <br /> Add the missing page_pool_destroy() calls in both error paths.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31646
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()<br /> <br /> page_pool_create() can return an ERR_PTR on failure. The return value<br /> is used unconditionally in the loop that follows, passing the error<br /> pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(),<br /> which dereferences it, causing a kernel oops.<br /> <br /> Add an IS_ERR check after page_pool_create() to return early on failure.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31635
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: fix oversized RESPONSE authenticator length check<br /> <br /> rxgk_verify_response() decodes auth_len from the packet and is supposed<br /> to verify that it fits in the remaining bytes. The existing check is<br /> inverted, so oversized RESPONSE authenticators are accepted and passed<br /> to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an<br /> impossible length and hit BUG_ON(len).<br /> <br /> Decoded from the original latest-net reproduction logs with<br /> scripts/decode_stacktrace.sh:<br /> <br /> RIP: __skb_to_sgvec()<br /> [net/core/skbuff.c:5285 (discriminator 1)]<br /> Call Trace:<br /> skb_to_sgvec() [net/core/skbuff.c:5305]<br /> rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81]<br /> rxgk_verify_response() [net/rxrpc/rxgk.c:1268]<br /> rxrpc_process_connection()<br /> [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364<br /> net/rxrpc/conn_event.c:386]<br /> process_one_work() [kernel/workqueue.c:3281]<br /> worker_thread()<br /> [kernel/workqueue.c:3353 kernel/workqueue.c:3440]<br /> kthread() [kernel/kthread.c:436]<br /> ret_from_fork() [arch/x86/kernel/process.c:164]<br /> <br /> Reject authenticator lengths that exceed the remaining packet payload.
Severity CVSS v4.0: Pending analysis
Last modification:
18/05/2026

CVE-2026-31627
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: s3c24xx: check the size of the SMBUS message before using it<br /> <br /> The first byte of an i2c SMBUS message is the size, and it should be<br /> verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX<br /> before processing it.<br /> <br /> This is the same logic that was added in commit a6e04f05ce0b ("i2c:<br /> tegra: check msg length in SMBUS block read") to the i2c tegra driver.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31628
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/CPU: Fix FPDSS on Zen1<br /> <br /> Zen1&amp;#39;s hardware divider can leave, under certain circumstances, partial<br /> results from previous operations. Those results can be leaked by<br /> another, attacker thread.<br /> <br /> Fix that with a chicken bit.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31629
Publication date:
24/04/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: add missing return after LLCP_CLOSED checks<br /> <br /> In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket<br /> state is LLCP_CLOSED, the code correctly calls release_sock() and<br /> nfc_llcp_sock_put() but fails to return. Execution falls through to<br /> the remainder of the function, which calls release_sock() and<br /> nfc_llcp_sock_put() again. This results in a double release_sock()<br /> and a refcount underflow via double nfc_llcp_sock_put(), leading to<br /> a use-after-free.<br /> <br /> Add the missing return statements after the LLCP_CLOSED branches<br /> in both functions to prevent the fall-through.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026
Subscribe to Vulnerabilities