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-2022-50879

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool: Fix SEGFAULT<br /> <br /> find_insn() will return NULL in case of failure. Check insn in order<br /> to avoid a kernel Oops for NULL pointer dereference.
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50863

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: free unused skb to prevent memory leak<br /> <br /> This avoid potential memory leak under power saving mode.
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50864

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix shift-out-of-bounds due to too large exponent of block size<br /> <br /> If field s_log_block_size of superblock data is corrupted and too large,<br /> init_nilfs() and load_nilfs() still can trigger a shift-out-of-bounds<br /> warning followed by a kernel panic (if panic_on_warn is set):<br /> <br /> shift exponent 38973 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xcd/0x134<br /> ubsan_epilogue+0xb/0x50<br /> __ubsan_handle_shift_out_of_bounds.cold.12+0x17b/0x1f5<br /> init_nilfs.cold.11+0x18/0x1d [nilfs2]<br /> nilfs_mount+0x9b5/0x12b0 [nilfs2]<br /> ...<br /> <br /> This fixes the issue by adding and using a new helper function for getting<br /> block size with sanity check.
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50865

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix a signed-integer-overflow bug in tcp_add_backlog()<br /> <br /> The type of sk_rcvbuf and sk_sndbuf in struct sock is int, and<br /> in tcp_add_backlog(), the variable limit is caculated by adding<br /> sk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max value<br /> of int and overflow. This patch reduces the limit budget by<br /> halving the sndbuf to solve this issue since ACK packets are much<br /> smaller than the payload.
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50866

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: pxa: fix null-pointer dereference in filter()<br /> <br /> kasprintf() would return NULL pointer when kmalloc() fail to allocate.<br /> Need to check the return pointer before calling strcmp().
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50867

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a6xx: Fix kvzalloc vs state_kcalloc usage<br /> <br /> adreno_show_object() is a trap! It will re-allocate the pointer it is<br /> passed on first call, when the data is ascii85 encoded, using kvmalloc/<br /> kvfree(). Which means the data *passed* to it must be kvmalloc&amp;#39;d, ie.<br /> we cannot use the state_kcalloc() helper.<br /> <br /> This partially reverts commit ec8f1813bf8d ("drm/msm/a6xx: Replace<br /> kcalloc() with kvzalloc()"), but adds the missing kvfree() to fix the<br /> memory leak that was present previously. And adds a warning comment.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/507014/
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50868

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: amd - Fix PCI device refcount leak<br /> <br /> for_each_pci_dev() is implemented by pci_get_device(). The comment of<br /> pci_get_device() says that it will increase the reference count for the<br /> returned pci_dev and also decrease the reference count for the input<br /> pci_dev @from if it is not NULL.<br /> <br /> If we break for_each_pci_dev() loop with pdev not NULL, we need to call<br /> pci_dev_put() to decrease the reference count. Add the missing<br /> pci_dev_put() for the normal and error path.
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50869

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix slab-out-of-bounds in r_page<br /> <br /> When PAGE_SIZE is 64K, if read_log_page is called by log_read_rst for<br /> the first time, the size of *buffer would be equal to<br /> DefaultLogPageSize(4K).But for *buffer operations like memcpy,<br /> if the memory area size(n) which being assigned to buffer is larger<br /> than 4K (log-&gt;page_size(64K) or bytes(64K-page_off)), it will cause<br /> an out of boundary error.<br /> Call trace:<br /> [...]<br /> kasan_report+0x44/0x130<br /> check_memory_region+0xf8/0x1a0<br /> memcpy+0xc8/0x100<br /> ntfs_read_run_nb+0x20c/0x460<br /> read_log_page+0xd0/0x1f4<br /> log_read_rst+0x110/0x75c<br /> log_replay+0x1e8/0x4aa0<br /> ntfs_loadlog_and_replay+0x290/0x2d0<br /> ntfs_fill_super+0x508/0xec0<br /> get_tree_bdev+0x1fc/0x34c<br /> [...]<br /> <br /> Fix this by setting variable r_page to NULL in log_read_rst.
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50870

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: avoid device tree lookups in rtas_os_term()<br /> <br /> rtas_os_term() is called during panic. Its behavior depends on a couple<br /> of conditions in the /rtas node of the device tree, the traversal of<br /> which entails locking and local IRQ state changes. If the kernel panics<br /> while devtree_lock is held, rtas_os_term() as currently written could<br /> hang.<br /> <br /> Instead of discovering the relevant characteristics at panic time,<br /> cache them in file-static variables at boot. Note the lookup for<br /> "ibm,extended-os-term" is converted to of_property_read_bool() since it<br /> is a boolean property, not an RTAS function token.<br /> <br /> [mpe: Incorporate suggested change from Nick]
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50853

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Fix a credential leak in _nfs4_discover_trunking()
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50854

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: virtual_ncidev: Fix memory leak in virtual_nci_send()<br /> <br /> skb should be free in virtual_nci_send(), otherwise kmemleak will report<br /> memleak.<br /> <br /> Steps for reproduction (simulated in qemu):<br /> cd tools/testing/selftests/nci<br /> make<br /> ./nci_dev<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888107588000 (size 208):<br /> comm "nci_dev", pid 206, jiffies 4294945376 (age 368.248s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 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:<br /> [] __alloc_skb+0x1da/0x290<br /> [] nci_send_cmd+0xa3/0x350<br /> [] nci_reset_req+0x6b/0xa0<br /> [] __nci_request+0x90/0x250<br /> [] nci_dev_up+0x217/0x5b0<br /> [] nfc_dev_up+0x114/0x220<br /> [] nfc_genl_dev_up+0x94/0xe0<br /> [] genl_family_rcv_msg_doit.isra.14+0x228/0x2d0<br /> [] genl_rcv_msg+0x35c/0x640<br /> [] netlink_rcv_skb+0x11e/0x350<br /> [] genl_rcv+0x24/0x40<br /> [] netlink_unicast+0x43f/0x640<br /> [] netlink_sendmsg+0x73a/0xbf0<br /> [] __sys_sendto+0x324/0x370<br /> [] __x64_sys_sendto+0xdd/0x1b0<br /> [] do_syscall_64+0x3f/0x90
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025

CVE-2022-50855

Fecha de publicación:
30/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: prevent leak of lsm program after failed attach<br /> <br /> In [0], we added the ability to bpf_prog_attach LSM programs to cgroups,<br /> but in our validation to make sure the prog is meant to be attached to<br /> BPF_LSM_CGROUP, we return too early if the check fails. This results in<br /> lack of decrementing prog&amp;#39;s refcnt (through bpf_prog_put)<br /> leaving the LSM program alive past the point of the expected lifecycle.<br /> This fix allows for the decrement to take place.<br /> <br /> [0] https://lore.kernel.org/all/20220628174314.1216643-4-sdf@google.com/
Gravedad: Pendiente de análisis
Última modificación:
31/12/2025