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-2023-53337

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: do not write dirty data after degenerating to read-only<br /> <br /> According to syzbot&amp;#39;s report, mark_buffer_dirty() called from<br /> nilfs_segctor_do_construct() outputs a warning with some patterns after<br /> nilfs2 detects metadata corruption and degrades to read-only mode.<br /> <br /> After such read-only degeneration, page cache data may be cleared through<br /> nilfs_clear_dirty_page() which may also clear the uptodate flag for their<br /> buffer heads. However, even after the degeneration, log writes are still<br /> performed by unmount processing etc., which causes mark_buffer_dirty() to<br /> be called for buffer heads without the "uptodate" flag and causes the<br /> warning.<br /> <br /> Since any writes should not be done to a read-only file system in the<br /> first place, this fixes the warning in mark_buffer_dirty() by letting<br /> nilfs_segctor_do_construct() abort early if in read-only mode.<br /> <br /> This also changes the retry check of nilfs_segctor_write_out() to avoid<br /> unnecessary log write retries if it detects -EROFS that<br /> nilfs_segctor_do_construct() returned.
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2023-53338

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lwt: Fix return values of BPF xmit ops<br /> <br /> BPF encap ops can return different types of positive values, such like<br /> NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function<br /> skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return<br /> values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in<br /> ip(6)_finish_output2. When this happens, skbs that have been freed would<br /> continue to the neighbor subsystem, causing use-after-free bug and<br /> kernel crashes.<br /> <br /> To fix the incorrect behavior, skb_do_redirect return values can be<br /> simply discarded, the same as tc-egress behavior. On the other hand,<br /> bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU<br /> information. Thus convert its return values to avoid the conflict with<br /> LWTUNNEL_XMIT_CONTINUE.
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50363

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skmsg: pass gfp argument to alloc_sk_msg()<br /> <br /> syzbot found that alloc_sk_msg() could be called from a<br /> non sleepable context. sk_psock_verdict_recv() uses<br /> rcu_read_lock() protection.<br /> <br /> We need the callers to pass a gfp_t argument to avoid issues.<br /> <br /> syzbot report was:<br /> <br /> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274<br /> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414<br /> preempt_count: 0, expected: 0<br /> RCU nest depth: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106<br /> __might_resched+0x538/0x6a0 kernel/sched/core.c:9877<br /> might_alloc include/linux/sched/mm.h:274 [inline]<br /> slab_pre_alloc_hook mm/slab.h:700 [inline]<br /> slab_alloc_node mm/slub.c:3162 [inline]<br /> slab_alloc mm/slub.c:3256 [inline]<br /> kmem_cache_alloc_trace+0x59/0x310 mm/slub.c:3287<br /> kmalloc include/linux/slab.h:600 [inline]<br /> kzalloc include/linux/slab.h:733 [inline]<br /> alloc_sk_msg net/core/skmsg.c:507 [inline]<br /> sk_psock_skb_ingress_self+0x5c/0x330 net/core/skmsg.c:600<br /> sk_psock_verdict_apply+0x395/0x440 net/core/skmsg.c:1014<br /> sk_psock_verdict_recv+0x34d/0x560 net/core/skmsg.c:1201<br /> tcp_read_skb+0x4a1/0x790 net/ipv4/tcp.c:1770<br /> tcp_rcv_established+0x129d/0x1a10 net/ipv4/tcp_input.c:5971<br /> tcp_v4_do_rcv+0x479/0xac0 net/ipv4/tcp_ipv4.c:1681<br /> sk_backlog_rcv include/net/sock.h:1109 [inline]<br /> __release_sock+0x1d8/0x4c0 net/core/sock.c:2906<br /> release_sock+0x5d/0x1c0 net/core/sock.c:3462<br /> tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1483<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> __sys_sendto+0x46d/0x5f0 net/socket.c:2117<br /> __do_sys_sendto net/socket.c:2129 [inline]<br /> __se_sys_sendto net/socket.c:2125 [inline]<br /> __x64_sys_sendto+0xda/0xf0 net/socket.c:2125<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50364

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: mux: reg: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref in resource_size(), if platform_get_resource()<br /> returns NULL, move calling resource_size() after devm_ioremap_resource() that<br /> will check &amp;#39;res&amp;#39; to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50365

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skbuff: Account for tail adjustment during pull operations<br /> <br /> Extending the tail can have some unexpected side effects if a program uses<br /> a helper like BPF_FUNC_skb_pull_data to read partial content beyond the<br /> head skb headlen when all the skbs in the gso frag_list are linear with no<br /> head_frag -<br /> <br /> kernel BUG at net/core/skbuff.c:4219!<br /> pc : skb_segment+0xcf4/0xd2c<br /> lr : skb_segment+0x63c/0xd2c<br /> Call trace:<br /> skb_segment+0xcf4/0xd2c<br /> __udp_gso_segment+0xa4/0x544<br /> udp4_ufo_fragment+0x184/0x1c0<br /> inet_gso_segment+0x16c/0x3a4<br /> skb_mac_gso_segment+0xd4/0x1b0<br /> __skb_gso_segment+0xcc/0x12c<br /> udp_rcv_segment+0x54/0x16c<br /> udp_queue_rcv_skb+0x78/0x144<br /> udp_unicast_rcv_skb+0x8c/0xa4<br /> __udp4_lib_rcv+0x490/0x68c<br /> udp_rcv+0x20/0x30<br /> ip_protocol_deliver_rcu+0x1b0/0x33c<br /> ip_local_deliver+0xd8/0x1f0<br /> ip_rcv+0x98/0x1a4<br /> deliver_ptype_list_skb+0x98/0x1ec<br /> __netif_receive_skb_core+0x978/0xc60<br /> <br /> Fix this by marking these skbs as GSO_DODGY so segmentation can handle<br /> the tail updates accordingly.
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50366

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue<br /> <br /> When value
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50367

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: fix UAF/GPF bug in nilfs_mdt_destroy<br /> <br /> In alloc_inode, inode_init_always() could return -ENOMEM if<br /> security_inode_alloc() fails, which causes inode-&gt;i_private<br /> uninitialized. Then nilfs_is_metadata_file_inode() returns<br /> true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),<br /> which frees the uninitialized inode-&gt;i_private<br /> and leads to crashes(e.g., UAF/GPF).<br /> <br /> Fix this by moving security_inode_alloc just prior to<br /> this_cpu_inc(nr_inodes)
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50368

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dsi: fix memory corruption with too many bridges<br /> <br /> Add the missing sanity check on the bridge counter to avoid corrupting<br /> data beyond the fixed-sized bridge array in case there are ever more<br /> than eight bridges.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502668/
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50369

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vkms: Fix null-ptr-deref in vkms_release()<br /> <br /> A null-ptr-deref is triggered when it tries to destroy the workqueue in<br /> vkms-&gt;output.composer_workq in vkms_release().<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24<br /> RIP: 0010:destroy_workqueue+0x2f/0x710<br /> ...<br /> Call Trace:<br /> <br /> ? vkms_config_debugfs_init+0x50/0x50 [vkms]<br /> __devm_drm_dev_alloc+0x15a/0x1c0 [drm]<br /> vkms_init+0x245/0x1000 [vkms]<br /> do_one_initcall+0xd0/0x4f0<br /> do_init_module+0x1a4/0x680<br /> load_module+0x6249/0x7110<br /> __do_sys_finit_module+0x140/0x200<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The reason is that an OOM happened which triggers the destroy of the<br /> workqueue, however, the workqueue is alloced in the later process,<br /> thus a null-ptr-deref happened. A simple call graph is shown as below:<br /> <br /> vkms_init()<br /> vkms_create()<br /> devm_drm_dev_alloc()<br /> __devm_drm_dev_alloc()<br /> devm_drm_dev_init()<br /> devm_add_action_or_reset()<br /> devm_add_action() # an error happened<br /> devm_drm_dev_init_release()<br /> drm_dev_put()<br /> kref_put()<br /> drm_dev_release()<br /> vkms_release()<br /> destroy_workqueue() # null-ptr-deref happened<br /> vkms_modeset_init()<br /> vkms_output_init()<br /> vkms_crtc_init() # where the workqueue get allocated<br /> <br /> Fix this by checking if composer_workq is NULL before passing it to<br /> the destroy_workqueue() in vkms_release().
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50370

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: designware: Fix handling of real but unexpected device interrupts<br /> <br /> Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI<br /> IDs") caused a regression on certain Gigabyte motherboards for Intel<br /> Alder Lake-S where system crashes to NULL pointer dereference in<br /> i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep").<br /> <br /> I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made<br /> following notes:<br /> <br /> - Issue happens when resuming from S3 but not when resuming from<br /> "s2idle"<br /> - PCI device 00:15.0 == i2c_designware.0 is already in D0 state when<br /> system enters into pci_pm_resume_noirq() while all other i2c_designware<br /> PCI devices are in D3. Devices were runtime suspended and in D3 prior<br /> entering into suspend<br /> - Interrupt comes after pci_pm_resume_noirq() when device interrupts are<br /> re-enabled<br /> - According to register dump the interrupt really comes from the<br /> i2c_designware.0. Controller is enabled, I2C target address register<br /> points to a one detectable I2C device address 0x60 and the<br /> DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and<br /> TX_EMPTY bits are set indicating completed I2C transaction.<br /> <br /> My guess is that the firmware uses this controller to communicate with<br /> an on-board I2C device during resume but does not disable the controller<br /> before giving control to an operating system.<br /> <br /> I was told the UEFI update fixes this but never the less it revealed the<br /> driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device<br /> is supposed to be idle and state variables are not set (especially the<br /> dev-&gt;msgs pointer which may point to NULL or stale old data).<br /> <br /> Introduce a new software status flag STATUS_ACTIVE indicating when the<br /> controller is active in driver point of view. Now treat all interrupts<br /> that occur when is not set as unexpected and mask all interrupts from<br /> the controller.
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50354

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix kfd_process_device_init_vm error handling<br /> <br /> Should only destroy the ib_mem and let process cleanup worker to free<br /> the outstanding BOs. Reset the pointer in pdd-&gt;qpd structure, to avoid<br /> NULL pointer access in process destroy worker.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Call Trace:<br /> amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu]<br /> kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu]<br /> kfd_process_destroy_pdds+0x71/0x190 [amdgpu]<br /> kfd_process_wq_release+0x2a2/0x3b0 [amdgpu]<br /> process_one_work+0x2a1/0x600<br /> worker_thread+0x39/0x3d0
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025

CVE-2022-50355

Fecha de publicación:
17/09/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vt6655: fix some erroneous memory clean-up loops<br /> <br /> In some initialization functions of this driver, memory is allocated with<br /> &amp;#39;i&amp;#39; acting as an index variable and increasing from 0. The commit in<br /> "Fixes" introduces some clean-up codes in case of allocation failure,<br /> which free memory in reverse order with &amp;#39;i&amp;#39; decreasing to 0. However,<br /> there are some problems:<br /> - The case i=0 is left out. Thus memory is leaked.<br /> - In case memory allocation fails right from the start, the memory<br /> freeing loops will start with i=-1 and invalid memory locations will<br /> be accessed.<br /> <br /> One of these loops has been fixed in commit c8ff91535880 ("staging:<br /> vt6655: fix potential memory leak"). Fix the remaining erroneous loops.
Gravedad: Pendiente de análisis
Última modificación:
17/09/2025