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 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-31641
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31642
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31643
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31644
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31645
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31646
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31627
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31628
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31629
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** 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.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31630
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: proc: size address buffers for %pISpc output<br /> <br /> The AF_RXRPC procfs helpers format local and remote socket addresses into<br /> fixed 50-byte stack buffers with "%pISpc".<br /> <br /> That is too small for the longest current-tree IPv6-with-port form the<br /> formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a<br /> dotted-quad tail not only for v4mapped addresses, but also for ISATAP<br /> addresses via ipv6_addr_is_isatap().<br /> <br /> As a result, a case such as<br /> <br /> [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535<br /> <br /> is possible with the current formatter. That is 50 visible characters, so<br /> 51 bytes including the trailing NUL, which does not fit in the existing<br /> char[50] buffers used by net/rxrpc/proc.c.<br /> <br /> Size the buffers from the formatter&amp;#39;s maximum textual form and switch the<br /> call sites to scnprintf().<br /> <br /> Changes since v1:<br /> - correct the changelog to cite the actual maximum current-tree case<br /> explicitly<br /> - frame the proof around the ISATAP formatting path instead of the earlier<br /> mapped-v4 example
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31631
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix buffer overread in rxgk_do_verify_authenticator()<br /> <br /> Fix rxgk_do_verify_authenticator() to check the buffer size before checking<br /> the nonce.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026

CVE-2026-31632
Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix leak of rxgk context in rxgk_verify_response()<br /> <br /> Fix rxgk_verify_response() to clean up the rxgk context it creates.
Gravedad: Pendiente de análisis
Última modificación:
24/04/2026
Suscribirse a Vulnerabilidades