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

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages<br /> <br /> On big endian architectures, it is possible to run into a memory out of<br /> bounds pointer dereference when FCP targets are zoned.<br /> <br /> In lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl-&gt;sge_len) is<br /> referencing a little endian formatted sgl-&gt;sge_len value. So, the memcpy<br /> can cause big endian systems to crash.<br /> <br /> Redefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are<br /> referring to a little endian formatted data structure. And, update the<br /> routine with proper le32_to_cpu macro usages.
Severity CVSS v4.0: Pending analysis
Last modification:
29/09/2025

CVE-2023-0714

Publication date:
17/08/2024
The Metform Elementor Contact Form Builder for WordPress is vulnerable to Arbitrary File Upload due to insufficient file type validation in versions up to, and including, 3.2.4. This allows unauthenticated visitors to perform a "double extension" attack and upload files containing a malicious extension but ending with a benign extension, which may make remote code execution possible in some configurations.
Severity CVSS v4.0: Pending analysis
Last modification:
23/04/2025

CVE-2024-7887

Publication date:
17/08/2024
A vulnerability was found in LimeSurvey 6.3.0-231016 and classified as problematic. Affected by this issue is some unknown functionality of the file /index.php of the component File Upload. The manipulation of the argument size leads to denial of service. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
Severity CVSS v4.0: MEDIUM
Last modification:
30/01/2026

CVE-2024-42317

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: avoid PMD-size page cache if needed<br /> <br /> xarray can&amp;#39;t support arbitrary page cache size. the largest and supported<br /> page cache size is defined as MAX_PAGECACHE_ORDER by commit 099d90642a71<br /> ("mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray"). However,<br /> it&amp;#39;s possible to have 512MB page cache in the huge memory&amp;#39;s collapsing<br /> path on ARM64 system whose base page size is 64KB. 512MB page cache is<br /> breaking the limitation and a warning is raised when the xarray entry is<br /> split as shown in the following example.<br /> <br /> [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize<br /> KernelPageSize: 64 kB<br /> [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c<br /> :<br /> int main(int argc, char **argv)<br /> {<br /> const char *filename = TEST_XFS_FILENAME;<br /> int fd = 0;<br /> void *buf = (void *)-1, *p;<br /> int pgsize = getpagesize();<br /> int ret = 0;<br /> <br /> if (pgsize != 0x10000) {<br /> fprintf(stdout, "System with 64KB base page size is required!\n");<br /> return -EPERM;<br /> }<br /> <br /> system("echo 0 &gt; /sys/devices/virtual/bdi/253:0/read_ahead_kb");<br /> system("echo 1 &gt; /proc/sys/vm/drop_caches");<br /> <br /> /* Open the xfs file */<br /> fd = open(filename, O_RDONLY);<br /> assert(fd &gt; 0);<br /> <br /> /* Create VMA */<br /> buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0);<br /> assert(buf != (void *)-1);<br /> fprintf(stdout, "mapped buffer at 0x%p\n", buf);<br /> <br /> /* Populate VMA */<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE);<br /> assert(ret == 0);<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ);<br /> assert(ret == 0);<br /> <br /> /* Collapse VMA */<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);<br /> assert(ret == 0);<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE);<br /> if (ret) {<br /> fprintf(stdout, "Error %d to madvise(MADV_COLLAPSE)\n", errno);<br /> goto out;<br /> }<br /> <br /> /* Split xarray entry. Write permission is needed */<br /> munmap(buf, TEST_MEM_SIZE);<br /> buf = (void *)-1;<br /> close(fd);<br /> fd = open(filename, O_RDWR);<br /> assert(fd &gt; 0);<br /> fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,<br /> TEST_MEM_SIZE - pgsize, pgsize);<br /> out:<br /> if (buf != (void *)-1)<br /> munmap(buf, TEST_MEM_SIZE);<br /> if (fd &gt; 0)<br /> close(fd);<br /> <br /> return ret;<br /> }<br /> <br /> [root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test<br /> [root@dhcp-10-26-1-207 ~]# /tmp/test<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128<br /> Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \<br /> nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \<br /> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \<br /> ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse \<br /> xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 virtio_net \<br /> sha1_ce net_failover virtio_blk virtio_console failover dimlib virtio_mmio<br /> CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : xas_split_alloc+0xf8/0x128<br /> lr : split_huge_page_to_list_to_order+0x1c4/0x780<br /> sp : ffff8000ac32f660<br /> x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0<br /> x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d<br /> x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c<br /> x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8<br /> x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40<br /> x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000<br /> Call trace:<br /> xas_split_alloc+0xf8/0x128<br /> split_huge_page_to_list_to_order+0x1c4/0x780<br /> truncate_inode_partial_folio+0xdc/0x160<br /> truncate_inode_pages_range+0x1b4/0x4a8<br /> truncate_pagecache_range+0x84/0xa<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
07/10/2025

CVE-2024-42315

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix potential deadlock on __exfat_get_dentry_set<br /> <br /> When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array<br /> is allocated in __exfat_get_entry_set. The problem is that the bh-array is<br /> allocated with GFP_KERNEL. It does not make sense. In the following cases,<br /> a deadlock for sbi-&gt;s_lock between the two processes may occur.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> kswapd<br /> balance_pgdat<br /> lock(fs_reclaim)<br /> exfat_iterate<br /> lock(&amp;sbi-&gt;s_lock)<br /> exfat_readdir<br /> exfat_get_uniname_from_ext_entry<br /> exfat_get_dentry_set<br /> __exfat_get_dentry_set<br /> kmalloc_array<br /> ...<br /> lock(fs_reclaim)<br /> ...<br /> evict<br /> exfat_evict_inode<br /> lock(&amp;sbi-&gt;s_lock)<br /> <br /> To fix this, let&amp;#39;s allocate bh-array with GFP_NOFS.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42319

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable()<br /> <br /> When mtk-cmdq unbinds, a WARN_ON message with condition<br /> pm_runtime_get_sync()
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42310

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes<br /> <br /> In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()<br /> is assigned to mode, which will lead to a NULL pointer dereference on<br /> failure of drm_mode_duplicate(). Add a check to avoid npd.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42311

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()<br /> <br /> Syzbot reports uninitialized value access issue as below:<br /> <br /> loop0: detected capacity change from 0 to 64<br /> =====================================================<br /> BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30<br /> hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30<br /> d_revalidate fs/namei.c:862 [inline]<br /> lookup_fast+0x89e/0x8e0 fs/namei.c:1649<br /> walk_component fs/namei.c:2001 [inline]<br /> link_path_walk+0x817/0x1480 fs/namei.c:2332<br /> path_lookupat+0xd9/0x6f0 fs/namei.c:2485<br /> filename_lookup+0x22e/0x740 fs/namei.c:2515<br /> user_path_at_empty+0x8b/0x390 fs/namei.c:2924<br /> user_path_at include/linux/namei.h:57 [inline]<br /> do_mount fs/namespace.c:3689 [inline]<br /> __do_sys_mount fs/namespace.c:3898 [inline]<br /> __se_sys_mount+0x66b/0x810 fs/namespace.c:3875<br /> __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]<br /> BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366<br /> hfs_ext_read_extent fs/hfs/extent.c:196 [inline]<br /> hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366<br /> block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271<br /> hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39<br /> filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426<br /> do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553<br /> do_read_cache_page mm/filemap.c:3595 [inline]<br /> read_cache_page+0xfb/0x2f0 mm/filemap.c:3604<br /> read_mapping_page include/linux/pagemap.h:755 [inline]<br /> hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78<br /> hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204<br /> hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406<br /> mount_bdev+0x628/0x920 fs/super.c:1359<br /> hfs_mount+0xcd/0xe0 fs/hfs/super.c:456<br /> legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610<br /> vfs_get_tree+0xdc/0x5d0 fs/super.c:1489<br /> do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145<br /> path_mount+0xf98/0x26a0 fs/namespace.c:3475<br /> do_mount fs/namespace.c:3488 [inline]<br /> __do_sys_mount fs/namespace.c:3697 [inline]<br /> __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674<br /> __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> Uninit was created at:<br /> __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590<br /> __alloc_pages_node include/linux/gfp.h:238 [inline]<br /> alloc_pages_node include/linux/gfp.h:261 [inline]<br /> alloc_slab_page mm/slub.c:2190 [inline]<br /> allocate_slab mm/slub.c:2354 [inline]<br /> new_slab+0x2d7/0x1400 mm/slub.c:2407<br /> ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540<br /> __slab_alloc mm/slub.c:3625 [inline]<br /> __slab_alloc_node mm/slub.c:3678 [inline]<br /> slab_alloc_node mm/slub.c:3850 [inline]<br /> kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879<br /> alloc_inode_sb include/linux/fs.h:3018 [inline]<br /> hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165<br /> alloc_inode+0x83/0x440 fs/inode.c:260<br /> new_inode_pseudo fs/inode.c:1005 [inline]<br /> new_inode+0x38/0x4f0 fs/inode.c:1031<br /> hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186<br /> hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228<br /> vfs_mkdir+0x49a/0x700 fs/namei.c:4126<br /> do_mkdirat+0x529/0x810 fs/namei.c:4149<br /> __do_sys_mkdirat fs/namei.c:4164 [inline]<br /> __se_sys_mkdirat fs/namei.c:4162 [inline]<br /> __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> It missed to initialize .tz_secondswest, .cached_start and .cached_blocks<br /> fields in struct hfs_inode_info after hfs_alloc_inode(), fix it.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42312

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysctl: always initialize i_uid/i_gid<br /> <br /> Always initialize i_uid/i_gid inside the sysfs core so set_ownership()<br /> can safely skip setting them.<br /> <br /> Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of<br /> i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when<br /> set_ownership() was not implemented. It also missed adjusting<br /> net_ctl_set_ownership() to use the same default values in case the<br /> computation of a better value failed.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42313

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: fix use after free in vdec_close<br /> <br /> There appears to be a possible use after free with vdec_close().<br /> The firmware will add buffer release work to the work queue through<br /> HFI callbacks as a normal part of decoding. Randomly closing the<br /> decoder device from userspace during normal decoding can incur<br /> a read after free for inst.<br /> <br /> Fix it by cancelling the work in vdec_close.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42314

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix extent map use-after-free when adding pages to compressed bio<br /> <br /> At add_ra_bio_pages() we are accessing the extent map to calculate<br /> &amp;#39;add_size&amp;#39; after we dropped our reference on the extent map, resulting<br /> in a use-after-free. Fix this by computing &amp;#39;add_size&amp;#39; before dropping our<br /> extent map reference.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42316

Publication date:
17/08/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mglru: fix div-by-zero in vmpressure_calc_level()<br /> <br /> evict_folios() uses a second pass to reclaim folios that have gone through<br /> page writeback and become clean before it finishes the first pass, since<br /> folio_rotate_reclaimable() cannot handle those folios due to the<br /> isolation.<br /> <br /> The second pass tries to avoid potential double counting by deducting<br /> scan_control-&gt;nr_scanned. However, this can result in underflow of<br /> nr_scanned, under a condition where shrink_folio_list() does not increment<br /> nr_scanned, i.e., when folio_trylock() fails.<br /> <br /> The underflow can cause the divisor, i.e., scale=scanned+reclaimed in<br /> vmpressure_calc_level(), to become zero, resulting in the following crash:<br /> <br /> [exception RIP: vmpressure_work_fn+101]<br /> process_one_work at ffffffffa3313f2b<br /> <br /> Since scan_control-&gt;nr_scanned has no established semantics, the potential<br /> double counting has minimal risks. Therefore, fix the problem by not<br /> deducting scan_control-&gt;nr_scanned in evict_folios().
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025