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-50647

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: Make port I/O string accessors actually work<br /> <br /> Fix port I/O string accessors such as `insb&amp;#39;, `outsb&amp;#39;, etc. which use<br /> the physical PCI port I/O address rather than the corresponding memory<br /> mapping to get at the requested location, which in turn breaks at least<br /> accesses made by our parport driver to a PCIe parallel port such as:<br /> <br /> PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 20<br /> parport0: PC-style at 0x1000 (0x1008), irq 20, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP]<br /> <br /> causing a memory access fault:<br /> <br /> Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000001008<br /> Oops [#1]<br /> Modules linked in:<br /> CPU: 1 PID: 350 Comm: cat Not tainted 6.0.0-rc2-00283-g10d4879f9ef0-dirty #23<br /> Hardware name: SiFive HiFive Unmatched A00 (DT)<br /> epc : parport_pc_fifo_write_block_pio+0x266/0x416<br /> ra : parport_pc_fifo_write_block_pio+0xb4/0x416<br /> epc : ffffffff80542c3e ra : ffffffff80542a8c sp : ffffffd88899fc60<br /> gp : ffffffff80fa2700 tp : ffffffd882b1e900 t0 : ffffffd883d0b000<br /> t1 : ffffffffff000002 t2 : 4646393043330a38 s0 : ffffffd88899fcf0<br /> s1 : 0000000000001000 a0 : 0000000000000010 a1 : 0000000000000000<br /> a2 : ffffffd883d0a010 a3 : 0000000000000023 a4 : 00000000ffff8fbb<br /> a5 : ffffffd883d0a001 a6 : 0000000100000000 a7 : ffffffc800000000<br /> s2 : ffffffffff000002 s3 : ffffffff80d28880 s4 : ffffffff80fa1f50<br /> s5 : 0000000000001008 s6 : 0000000000000008 s7 : ffffffd883d0a000<br /> s8 : 0004000000000000 s9 : ffffffff80dc1d80 s10: ffffffd8807e4000<br /> s11: 0000000000000000 t3 : 00000000000000ff t4 : 393044410a303930<br /> t5 : 0000000000001000 t6 : 0000000000040000<br /> status: 0000000200000120 badaddr: 0000000000001008 cause: 000000000000000f<br /> [] parport_pc_compat_write_block_pio+0xfe/0x200<br /> [] parport_write+0x46/0xf8<br /> [] lp_write+0x158/0x2d2<br /> [] vfs_write+0x8e/0x2c2<br /> [] ksys_write+0x52/0xc2<br /> [] sys_write+0xe/0x16<br /> [] ret_from_syscall+0x0/0x2<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> For simplicity address the problem by adding PCI_IOBASE to the physical<br /> address requested in the respective wrapper macros only, observing that<br /> the raw accessors such as `__insb&amp;#39;, `__outsb&amp;#39;, etc. are not supposed to<br /> be used other than by said macros. Remove the cast to `long&amp;#39; that is no<br /> longer needed on `addr&amp;#39; now that it is used as an offset from PCI_IOBASE<br /> and add parentheses around `addr&amp;#39; needed for predictable evaluation in<br /> macro expansion. No need to make said adjustments in separate changes<br /> given that current code is gravely broken and does not ever work.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50648

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix recursive locking direct_mutex in ftrace_modify_direct_caller<br /> <br /> Naveen reported recursive locking of direct_mutex with sample<br /> ftrace-direct-modify.ko:<br /> <br /> [ 74.762406] WARNING: possible recursive locking detected<br /> [ 74.762887] 6.0.0-rc6+ #33 Not tainted<br /> [ 74.763216] --------------------------------------------<br /> [ 74.763672] event-sample-fn/1084 is trying to acquire lock:<br /> [ 74.764152] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> register_ftrace_function+0x1f/0x180<br /> [ 74.764922]<br /> [ 74.764922] but task is already holding lock:<br /> [ 74.765421] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> modify_ftrace_direct+0x34/0x1f0<br /> [ 74.766142]<br /> [ 74.766142] other info that might help us debug this:<br /> [ 74.766701] Possible unsafe locking scenario:<br /> [ 74.766701]<br /> [ 74.767216] CPU0<br /> [ 74.767437] ----<br /> [ 74.767656] lock(direct_mutex);<br /> [ 74.767952] lock(direct_mutex);<br /> [ 74.768245]<br /> [ 74.768245] *** DEADLOCK ***<br /> [ 74.768245]<br /> [ 74.768750] May be due to missing lock nesting notation<br /> [ 74.768750]<br /> [ 74.769332] 1 lock held by event-sample-fn/1084:<br /> [ 74.769731] #0: ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> modify_ftrace_direct+0x34/0x1f0<br /> [ 74.770496]<br /> [ 74.770496] stack backtrace:<br /> [ 74.770884] CPU: 4 PID: 1084 Comm: event-sample-fn Not tainted ...<br /> [ 74.771498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...<br /> [ 74.772474] Call Trace:<br /> [ 74.772696] <br /> [ 74.772896] dump_stack_lvl+0x44/0x5b<br /> [ 74.773223] __lock_acquire.cold.74+0xac/0x2b7<br /> [ 74.773616] lock_acquire+0xd2/0x310<br /> [ 74.773936] ? register_ftrace_function+0x1f/0x180<br /> [ 74.774357] ? lock_is_held_type+0xd8/0x130<br /> [ 74.774744] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.775213] __mutex_lock+0x99/0x1010<br /> [ 74.775536] ? register_ftrace_function+0x1f/0x180<br /> [ 74.775954] ? slab_free_freelist_hook.isra.43+0x115/0x160<br /> [ 74.776424] ? ftrace_set_hash+0x195/0x220<br /> [ 74.776779] ? register_ftrace_function+0x1f/0x180<br /> [ 74.777194] ? kfree+0x3e1/0x440<br /> [ 74.777482] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.777941] ? __schedule+0xb40/0xb40<br /> [ 74.778258] ? register_ftrace_function+0x1f/0x180<br /> [ 74.778672] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.779128] register_ftrace_function+0x1f/0x180<br /> [ 74.779527] ? ftrace_set_filter_ip+0x33/0x70<br /> [ 74.779910] ? __schedule+0xb40/0xb40<br /> [ 74.780231] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.780678] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.781147] ftrace_modify_direct_caller+0x5b/0x90<br /> [ 74.781563] ? 0xffffffffa0201000<br /> [ 74.781859] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.782309] modify_ftrace_direct+0x1b2/0x1f0<br /> [ 74.782690] ? __schedule+0xb40/0xb40<br /> [ 74.783014] ? simple_thread+0x2a/0xb0 [ftrace_direct_modify]<br /> [ 74.783508] ? __schedule+0xb40/0xb40<br /> [ 74.783832] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.784294] simple_thread+0x76/0xb0 [ftrace_direct_modify]<br /> [ 74.784766] kthread+0xf5/0x120<br /> [ 74.785052] ? kthread_complete_and_exit+0x20/0x20<br /> [ 74.785464] ret_from_fork+0x22/0x30<br /> [ 74.785781] <br /> <br /> Fix this by using register_ftrace_function_nolock in<br /> ftrace_modify_direct_caller.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50649

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: adp5061: fix out-of-bounds read in adp5061_get_chg_type()<br /> <br /> ADP5061_CHG_STATUS_1_CHG_STATUS is masked with 0x07, which means a length<br /> of 8, but adp5061_chg_type array size is 4, may end up reading 4 elements<br /> beyond the end of the adp5061_chg_type[] array.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50650

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix reference state management for synchronous callbacks<br /> <br /> Currently, verifier verifies callback functions (sync and async) as if<br /> they will be executed once, (i.e. it explores execution state as if the<br /> function was being called once). The next insn to explore is set to<br /> start of subprog and the exit from nested frame is handled using<br /> curframe &gt; 0 and prepare_func_exit. In case of async callback it uses a<br /> customized variant of push_stack simulating a kind of branch to set up<br /> custom state and execution context for the async callback.<br /> <br /> While this approach is simple and works when callback really will be<br /> executed only once, it is unsafe for all of our current helpers which<br /> are for_each style, i.e. they execute the callback multiple times.<br /> <br /> A callback releasing acquired references of the caller may do so<br /> multiple times, but currently verifier sees it as one call inside the<br /> frame, which then returns to caller. Hence, it thinks it released some<br /> reference that the cb e.g. got access through callback_ctx (register<br /> filled inside cb from spilled typed register on stack).<br /> <br /> Similarly, it may see that an acquire call is unpaired inside the<br /> callback, so the caller will copy the reference state of callback and<br /> then will have to release the register with new ref_obj_ids. But again,<br /> the callback may execute multiple times, but the verifier will only<br /> account for acquired references for a single symbolic execution of the<br /> callback, which will cause leaks.<br /> <br /> Note that for async callback case, things are different. While currently<br /> we have bpf_timer_set_callback which only executes it once, even for<br /> multiple executions it would be safe, as reference state is NULL and<br /> check_reference_leak would force program to release state before<br /> BPF_EXIT. The state is also unaffected by analysis for the caller frame.<br /> Hence async callback is safe.<br /> <br /> Since we want the reference state to be accessible, e.g. for pointers<br /> loaded from stack through callback_ctx&amp;#39;s PTR_TO_STACK, we still have to<br /> copy caller&amp;#39;s reference_state to callback&amp;#39;s bpf_func_state, but we<br /> enforce that whatever references it adds to that reference_state has<br /> been released before it hits BPF_EXIT. This requires introducing a new<br /> callback_ref member in the reference state to distinguish between caller<br /> vs callee references. Hence, check_reference_leak now errors out if it<br /> sees we are in callback_fn and we have not released callback_ref refs.<br /> Since there can be multiple nested callbacks, like frame 0 -&gt; cb1 -&gt; cb2<br /> etc. we need to also distinguish between whether this particular ref<br /> belongs to this callback frame or parent, and only error for our own, so<br /> we store state-&gt;frameno (which is always non-zero for callbacks).<br /> <br /> In short, callbacks can read parent reference_state, but cannot mutate<br /> it, to be able to use pointers acquired by the caller. They must only<br /> undo their changes (by releasing their own acquired_refs before<br /> BPF_EXIT) on top of caller reference_state before returning (at which<br /> point the caller and callback state will match anyway, so no need to<br /> copy it back to caller).
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50651

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: eeprom: fix null-deref on genl_info in dump<br /> <br /> The similar fix as commit 46cdedf2a0fa ("ethtool: pse-pd: fix null-deref on<br /> genl_info in dump") is also needed for ethtool eeprom.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50638

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on in __es_tree_search caused by bad boot loader inode<br /> <br /> We got a issue as fllows:<br /> ==================================================================<br /> kernel BUG at fs/ext4/extents_status.c:203!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349<br /> RIP: 0010:ext4_es_end.isra.0+0x34/0x42<br /> RSP: 0018:ffffc9000143b768 EFLAGS: 00010203<br /> RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff<br /> RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0<br /> R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000<br /> FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __es_tree_search.isra.0+0x6d/0xf5<br /> ext4_es_cache_extent+0xfa/0x230<br /> ext4_cache_extents+0xd2/0x110<br /> ext4_find_extent+0x5d5/0x8c0<br /> ext4_ext_map_blocks+0x9c/0x1d30<br /> ext4_map_blocks+0x431/0xa50<br /> ext4_mpage_readpages+0x48e/0xe40<br /> ext4_readahead+0x47/0x50<br /> read_pages+0x82/0x530<br /> page_cache_ra_unbounded+0x199/0x2a0<br /> do_page_cache_ra+0x47/0x70<br /> page_cache_ra_order+0x242/0x400<br /> ondemand_readahead+0x1e8/0x4b0<br /> page_cache_sync_ra+0xf4/0x110<br /> filemap_get_pages+0x131/0xb20<br /> filemap_read+0xda/0x4b0<br /> generic_file_read_iter+0x13a/0x250<br /> ext4_file_read_iter+0x59/0x1d0<br /> vfs_read+0x28f/0x460<br /> ksys_read+0x73/0x160<br /> __x64_sys_read+0x1e/0x30<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> ==================================================================<br /> <br /> In the above issue, ioctl invokes the swap_inode_boot_loader function to<br /> swap inode and inode. However, inode contain incorrect imode and<br /> disordered extents, and i_nlink is set to 1. The extents check for inode in<br /> the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO.<br /> While links_count is set to 1, the extents are not initialized in<br /> swap_inode_boot_loader. After the ioctl command is executed successfully,<br /> the extents are swapped to inode, in this case, run the `cat` command<br /> to view inode. And Bug_ON is triggered due to the incorrect extents.<br /> <br /> When the boot loader inode is not initialized, its imode can be one of the<br /> following:<br /> 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and<br /> set to S_IFREG.<br /> 2) the imode is good type but not S_IFREG.<br /> 3) the imode is S_IFREG.<br /> <br /> The BUG_ON may be triggered by bypassing the check in cases 1 and 2.<br /> Therefore, when the boot loader inode is bad_inode or its imode is not<br /> S_IFREG, initialize the inode to avoid triggering the BUG.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50639

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io-wq: Fix memory leak in worker creation<br /> <br /> If the CPU mask allocation for a node fails, then the memory allocated for<br /> the &amp;#39;io_wqe&amp;#39; struct of the current node doesn&amp;#39;t get freed on the error<br /> handling path, since it has not yet been added to the &amp;#39;wqes&amp;#39; array.<br /> <br /> This was spotted when fuzzing v6.1-rc1 with Syzkaller:<br /> BUG: memory leak<br /> unreferenced object 0xffff8880093d5000 (size 1024):<br /> comm "syz-executor.2", pid 7701, jiffies 4295048595 (age 13.900s)<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 /> [] __kmem_cache_alloc_node+0x18e/0x720<br /> [] kmalloc_node_trace+0x2a/0x130<br /> [] io_wq_create+0x7b9/0xdc0<br /> [] io_uring_alloc_task_context+0x31e/0x59d<br /> [] __io_uring_add_tctx_node.cold+0x19/0x1ba<br /> [] io_uring_setup.cold+0x1b80/0x1dce<br /> [] __x64_sys_io_uring_setup+0x5d/0x80<br /> [] do_syscall_64+0x5d/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50640

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: core: Fix kernel panic when remove non-standard SDIO card<br /> <br /> SDIO tuple is only allocated for standard SDIO card, especially it causes<br /> memory corruption issues when the non-standard SDIO card has removed, which<br /> is because the card device&amp;#39;s reference counter does not increase for it at<br /> sdio_init_func(), but all SDIO card device reference counter gets decreased<br /> at sdio_release_func().
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50641

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HSI: omap_ssi: Fix refcount leak in ssi_probe<br /> <br /> When returning or breaking early from a<br /> for_each_available_child_of_node() loop, we need to explicitly call<br /> of_node_put() on the child node to possibly release the node.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50642

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_typec: zero out stale pointers<br /> <br /> `cros_typec_get_switch_handles` allocates four pointers when obtaining<br /> type-c switch handles. These pointers are all freed if failing to obtain<br /> any of them; therefore, pointers in `port` become stale. The stale<br /> pointers eventually cause use-after-free or double free in later code<br /> paths. Zeroing out all pointer fields after freeing to eliminate these<br /> stale pointers.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50643

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix xid leak in cifs_copy_file_range()<br /> <br /> If the file is used by swap, before return -EOPNOTSUPP, should<br /> free the xid, otherwise, the xid will be leaked.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50644

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe<br /> <br /> pm_runtime_get_sync() will increment pm usage counter.<br /> Forgetting to putting operation will result in reference leak.<br /> Add missing pm_runtime_put_sync in some error paths.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025