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-2024-56748

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()<br /> <br /> Hook "qed_ops-&gt;common-&gt;sb_init = qed_sb_init" does not release the DMA<br /> memory sb_virt when it fails. Add dma_free_coherent() to free it. This<br /> is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2024-56751

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: release nexthop on device removal<br /> <br /> The CI is hitting some aperiodic hangup at device removal time in the<br /> pmtu.sh self-test:<br /> <br /> unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6<br /> ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at<br /> dst_init+0x84/0x4a0<br /> dst_alloc+0x97/0x150<br /> ip6_dst_alloc+0x23/0x90<br /> ip6_rt_pcpu_alloc+0x1e6/0x520<br /> ip6_pol_route+0x56f/0x840<br /> fib6_rule_lookup+0x334/0x630<br /> ip6_route_output_flags+0x259/0x480<br /> ip6_dst_lookup_tail.constprop.0+0x5c2/0x940<br /> ip6_dst_lookup_flow+0x88/0x190<br /> udp_tunnel6_dst_lookup+0x2a7/0x4c0<br /> vxlan_xmit_one+0xbde/0x4a50 [vxlan]<br /> vxlan_xmit+0x9ad/0xf20 [vxlan]<br /> dev_hard_start_xmit+0x10e/0x360<br /> __dev_queue_xmit+0xf95/0x18c0<br /> arp_solicit+0x4a2/0xe00<br /> neigh_probe+0xaa/0xf0<br /> <br /> While the first suspect is the dst_cache, explicitly tracking the dst<br /> owing the last device reference via probes proved such dst is held by<br /> the nexthop in the originating fib6_info.<br /> <br /> Similar to commit f5b51fe804ec ("ipv6: route: purge exception on<br /> removal"), we need to explicitly release the originating fib info when<br /> disconnecting a to-be-removed device from a live ipv6 dst: move the<br /> fib6_info cleanup into ip6_dst_ifdown().<br /> <br /> Tested running:<br /> <br /> ./pmtu.sh cleanup_ipv6_exception<br /> <br /> in a tight loop for more than 400 iterations with no spat, running an<br /> unpatched kernel I observed a splat every ~10 iterations.
Severity CVSS v4.0: Pending analysis
Last modification:
02/05/2025

CVE-2024-56739

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: check if __rtc_read_time was successful in rtc_timer_do_work()<br /> <br /> If the __rtc_read_time call fails,, the struct rtc_time tm; may contain<br /> uninitialized data, or an illegal date/time read from the RTC hardware.<br /> <br /> When calling rtc_tm_to_ktime later, the result may be a very large value<br /> (possibly KTIME_MAX). If there are periodic timers in rtc-&gt;timerqueue,<br /> they will continually expire, may causing kernel softlockup.
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2025

CVE-2024-56730

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/9p/usbg: fix handling of the failed kzalloc() memory allocation<br /> <br /> On the linux-next, next-20241108 vanilla kernel, the coccinelle tool gave the<br /> following error report:<br /> <br /> ./net/9p/trans_usbg.c:912:5-11: ERROR: allocation function on line 911 returns<br /> NULL not ERR_PTR on failure<br /> <br /> kzalloc() failure is fixed to handle the NULL return case on the memory exhaustion.
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2025

CVE-2024-56729

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: Initialize cfid-&gt;tcon before performing network ops<br /> <br /> Avoid leaking a tcon ref when a lease break races with opening the<br /> cached directory. Processing the leak break might take a reference to<br /> the tcon in cached_dir_lease_break() and then fail to release the ref in<br /> cached_dir_offload_close, since cfid-&gt;tcon is still NULL.
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2025

CVE-2024-56743

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs_common: must not hold RCU while calling nfsd_file_put_local<br /> <br /> Move holding the RCU from nfs_to_nfsd_file_put_local to<br /> nfs_to_nfsd_net_put. It is the call to nfs_to-&gt;nfsd_serv_put that<br /> requires the RCU anyway (the puts for nfsd_file and netns were<br /> combined to avoid an extra indirect reference but that<br /> micro-optimization isn&amp;#39;t possible now).<br /> <br /> This fixes xfstests generic/013 and it triggering:<br /> <br /> "Voluntary context switch within RCU read-side critical section!"<br /> <br /> [ 143.545738] Call Trace:<br /> [ 143.546206] <br /> [ 143.546625] ? show_regs+0x6d/0x80<br /> [ 143.547267] ? __warn+0x91/0x140<br /> [ 143.547951] ? rcu_note_context_switch+0x496/0x5d0<br /> [ 143.548856] ? report_bug+0x193/0x1a0<br /> [ 143.549557] ? handle_bug+0x63/0xa0<br /> [ 143.550214] ? exc_invalid_op+0x1d/0x80<br /> [ 143.550938] ? asm_exc_invalid_op+0x1f/0x30<br /> [ 143.551736] ? rcu_note_context_switch+0x496/0x5d0<br /> [ 143.552634] ? wakeup_preempt+0x62/0x70<br /> [ 143.553358] __schedule+0xaa/0x1380<br /> [ 143.554025] ? _raw_spin_unlock_irqrestore+0x12/0x40<br /> [ 143.554958] ? try_to_wake_up+0x1fe/0x6b0<br /> [ 143.555715] ? wake_up_process+0x19/0x20<br /> [ 143.556452] schedule+0x2e/0x120<br /> [ 143.557066] schedule_preempt_disabled+0x19/0x30<br /> [ 143.557933] rwsem_down_read_slowpath+0x24d/0x4a0<br /> [ 143.558818] ? xfs_efi_item_format+0x50/0xc0 [xfs]<br /> [ 143.559894] down_read+0x4e/0xb0<br /> [ 143.560519] xlog_cil_commit+0x1b2/0xbc0 [xfs]<br /> [ 143.561460] ? _raw_spin_unlock+0x12/0x30<br /> [ 143.562212] ? xfs_inode_item_precommit+0xc7/0x220 [xfs]<br /> [ 143.563309] ? xfs_trans_run_precommits+0x69/0xd0 [xfs]<br /> [ 143.564394] __xfs_trans_commit+0xb5/0x330 [xfs]<br /> [ 143.565367] xfs_trans_roll+0x48/0xc0 [xfs]<br /> [ 143.566262] xfs_defer_trans_roll+0x57/0x100 [xfs]<br /> [ 143.567278] xfs_defer_finish_noroll+0x27a/0x490 [xfs]<br /> [ 143.568342] xfs_defer_finish+0x1a/0x80 [xfs]<br /> [ 143.569267] xfs_bunmapi_range+0x4d/0xb0 [xfs]<br /> [ 143.570208] xfs_itruncate_extents_flags+0x13d/0x230 [xfs]<br /> [ 143.571353] xfs_free_eofblocks+0x12e/0x190 [xfs]<br /> [ 143.572359] xfs_file_release+0x12d/0x140 [xfs]<br /> [ 143.573324] __fput+0xe8/0x2d0<br /> [ 143.573922] __fput_sync+0x1d/0x30<br /> [ 143.574574] nfsd_filp_close+0x33/0x60 [nfsd]<br /> [ 143.575430] nfsd_file_free+0x96/0x150 [nfsd]<br /> [ 143.576274] nfsd_file_put+0xf7/0x1a0 [nfsd]<br /> [ 143.577104] nfsd_file_put_local+0x18/0x30 [nfsd]<br /> [ 143.578070] nfs_close_local_fh+0x101/0x110 [nfs_localio]<br /> [ 143.579079] __put_nfs_open_context+0xc9/0x180 [nfs]<br /> [ 143.580031] nfs_file_clear_open_context+0x4a/0x60 [nfs]<br /> [ 143.581038] nfs_file_release+0x3e/0x60 [nfs]<br /> [ 143.581879] __fput+0xe8/0x2d0<br /> [ 143.582464] __fput_sync+0x1d/0x30<br /> [ 143.583108] __x64_sys_close+0x41/0x80<br /> [ 143.583823] x64_sys_call+0x189a/0x20d0<br /> [ 143.584552] do_syscall_64+0x64/0x170<br /> [ 143.585240] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 143.586185] RIP: 0033:0x7f3c5153efd7
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2025

CVE-2024-56740

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs/localio: must clear res.replen in nfs_local_read_done<br /> <br /> Otherwise memory corruption can occur due to NFSv3 LOCALIO reads<br /> leaving garbage in res.replen:<br /> - nfs3_read_done() copies that into server-&gt;read_hdrsize; from there<br /> nfs3_proc_read_setup() copies it to args.replen in new requests.<br /> - nfs3_xdr_enc_read3args() passes that to rpc_prepare_reply_pages()<br /> which includes it in hdrsize for xdr_init_pages, so that rq_rcv_buf<br /> contains a ridiculous len.<br /> - This is copied to rq_private_buf and xs_read_stream_request()<br /> eventually passes the kvec to sock_recvmsg() which receives incoming<br /> data into entirely the wrong place.<br /> <br /> This is easily reproduced with NFSv3 LOCALIO that is servicing reads<br /> when it is made to pivot back to using normal RPC. This switch back<br /> to using normal NFSv3 with RPC can occur for a few reasons but this<br /> issue was exposed with a test that stops and then restarts the NFSv3<br /> server while LOCALIO is performing heavy read IO.
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2025

CVE-2024-56741

Publication date:
29/12/2024
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Severity CVSS v4.0: Pending analysis
Last modification:
03/03/2025

CVE-2024-56742

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()<br /> <br /> Fix an unwind issue in mlx5vf_add_migration_pages().<br /> <br /> If a set of pages is allocated but fails to be added to the SG table,<br /> they need to be freed to prevent a memory leak.<br /> <br /> Any pages successfully added to the SG table will be freed as part of<br /> mlx5vf_free_data_buffer().
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2024-56745

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix reset_method_store() memory leak<br /> <br /> In reset_method_store(), a string is allocated via kstrndup() and assigned<br /> to the local "options". options is then used in with strsep() to find<br /> spaces:<br /> <br /> while ((name = strsep(&amp;options, " ")) != NULL) {<br /> <br /> If there are no remaining spaces, then options is set to NULL by strsep(),<br /> so the subsequent kfree(options) doesn&amp;#39;t free the memory allocated via<br /> kstrndup().<br /> <br /> Fix by using a separate tmp_options to iterate with strsep() so options is<br /> preserved.
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2024-56744

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()<br /> <br /> syzbot reports deadlock issue of f2fs as below:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted<br /> ------------------------------------------------------<br /> kswapd0/79 is trying to acquire lock:<br /> ffff888011824088 (&amp;sbi-&gt;sb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline]<br /> ffff888011824088 (&amp;sbi-&gt;sb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068<br /> <br /> but task is already holding lock:<br /> ffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (sb_internal#2){.+.+}-{0:0}:<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825<br /> percpu_down_read include/linux/percpu-rwsem.h:51 [inline]<br /> __sb_start_write include/linux/fs.h:1716 [inline]<br /> sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899<br /> f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842<br /> evict+0x4e8/0x9b0 fs/inode.c:725<br /> f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807<br /> evict+0x4e8/0x9b0 fs/inode.c:725<br /> dispose_list fs/inode.c:774 [inline]<br /> prune_icache_sb+0x239/0x2f0 fs/inode.c:963<br /> super_cache_scan+0x38c/0x4b0 fs/super.c:223<br /> do_shrink_slab+0x701/0x1160 mm/shrinker.c:435<br /> shrink_slab+0x1093/0x14d0 mm/shrinker.c:662<br /> shrink_one+0x43b/0x850 mm/vmscan.c:4818<br /> shrink_many mm/vmscan.c:4879 [inline]<br /> lru_gen_shrink_node mm/vmscan.c:4957 [inline]<br /> shrink_node+0x3799/0x3de0 mm/vmscan.c:5937<br /> kswapd_shrink_node mm/vmscan.c:6765 [inline]<br /> balance_pgdat mm/vmscan.c:6957 [inline]<br /> kswapd+0x1ca3/0x3700 mm/vmscan.c:7226<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> -&gt; #1 (fs_reclaim){+.+.}-{0:0}:<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825<br /> __fs_reclaim_acquire mm/page_alloc.c:3834 [inline]<br /> fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848<br /> might_alloc include/linux/sched/mm.h:318 [inline]<br /> prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493<br /> __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722<br /> alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265<br /> alloc_pages_noprof mm/mempolicy.c:2345 [inline]<br /> folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352<br /> filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010<br /> do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787<br /> read_mapping_folio include/linux/pagemap.h:1011 [inline]<br /> f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032<br /> f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079<br /> f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174<br /> f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785<br /> write_inode fs/fs-writeback.c:1503 [inline]<br /> __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723<br /> writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779<br /> sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849<br /> f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941<br /> __fput+0x23f/0x880 fs/file_table.c:431<br /> task_work_run+0x24f/0x310 kernel/task_work.c:228<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:114 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218<br /> do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
16/04/2025

CVE-2024-56728

Publication date:
29/12/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c<br /> <br /> Add error pointer check after calling otx2_mbox_get_rsp().
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2025