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

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix potential UAF in nfsd4_cb_getattr_release<br /> <br /> Once we drop the delegation reference, the fields embedded in it are no<br /> longer safe to access. Do that last.
Severity CVSS v4.0: Pending analysis
Last modification:
13/09/2024

CVE-2024-46697

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: ensure that nfsd4_fattr_args.context is zeroed out<br /> <br /> If nfsd4_encode_fattr4 ends up doing a "goto out" before we get to<br /> checking for the security label, then args.context will be set to<br /> uninitialized junk on the stack, which we&amp;#39;ll then try to free.<br /> Initialize it early.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2024

CVE-2024-46698

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video/aperture: optionally match the device in sysfb_disable()<br /> <br /> In aperture_remove_conflicting_pci_devices(), we currently only<br /> call sysfb_disable() on vga class devices. This leads to the<br /> following problem when the pimary device is not VGA compatible:<br /> <br /> 1. A PCI device with a non-VGA class is the boot display<br /> 2. That device is probed first and it is not a VGA device so<br /> sysfb_disable() is not called, but the device resources<br /> are freed by aperture_detach_platform_device()<br /> 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()<br /> 4. NULL pointer dereference via sysfb_disable() since the resources<br /> have already been freed by aperture_detach_platform_device() when<br /> it was called by the other device.<br /> <br /> Fix this by passing a device pointer to sysfb_disable() and checking<br /> the device to determine if we should execute it or not.<br /> <br /> v2: Fix build when CONFIG_SCREEN_INFO is not set<br /> v3: Move device check into the mutex<br /> Drop primary variable in aperture_remove_conflicting_pci_devices()<br /> Drop __init on pci sysfb_pci_dev_is_enabled()
Severity CVSS v4.0: Pending analysis
Last modification:
13/09/2024

CVE-2024-46699

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Disable preemption while updating GPU stats<br /> <br /> We forgot to disable preemption around the write_seqcount_begin/end() pair<br /> while updating GPU stats:<br /> <br /> [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d]<br /> [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]<br /> <br /> [ ] Call trace:<br /> [ ] __seqprop_assert.isra.0+0x128/0x150 [v3d]<br /> [ ] v3d_job_start_stats.isra.0+0x90/0x218 [v3d]<br /> [ ] v3d_bin_job_run+0x23c/0x388 [v3d]<br /> [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]<br /> [ ] process_one_work+0x62c/0xb48<br /> [ ] worker_thread+0x468/0x5b0<br /> [ ] kthread+0x1c4/0x1e0<br /> [ ] ret_from_fork+0x10/0x20<br /> <br /> Fix it.
Severity CVSS v4.0: Pending analysis
Last modification:
13/09/2024

CVE-2024-46700

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

CVE-2024-5628

Publication date:
13/09/2024
The Avada | Website Builder For WordPress &amp; eCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s fusion_button shortcode in all versions up to, and including, 3.11.9 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. NOTE: This vulnerability was partially fixed in 3.11.9. Additional hardening for alternate attack vectors was added to version 3.11.10.
Severity CVSS v4.0: Pending analysis
Last modification:
26/09/2024

CVE-2024-46694

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: avoid using null object of framebuffer<br /> <br /> Instead of using state-&gt;fb-&gt;obj[0] directly, get object from framebuffer<br /> by calling drm_gem_fb_get_obj() and return error code when object is<br /> null to avoid using null object of framebuffer.<br /> <br /> (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-46695

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux,smack: don&amp;#39;t bypass permissions check in inode_setsecctx hook<br /> <br /> Marek Gresko reports that the root user on an NFS client is able to<br /> change the security labels on files on an NFS filesystem that is<br /> exported with root squashing enabled.<br /> <br /> The end of the kerneldoc comment for __vfs_setxattr_noperm() states:<br /> <br /> * This function requires the caller to lock the inode&amp;#39;s i_mutex before it<br /> * is executed. It also assumes that the caller will make the appropriate<br /> * permission checks.<br /> <br /> nfsd_setattr() does do permissions checking via fh_verify() and<br /> nfsd_permission(), but those don&amp;#39;t do all the same permissions checks<br /> that are done by security_inode_setxattr() and its related LSM hooks do.<br /> <br /> Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),<br /> simplest solution appears to be to replace the call to<br /> __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This<br /> fixes the above issue and has the added benefit of causing nfsd to<br /> recall conflicting delegations on a file when a client tries to change<br /> its security label.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-46684

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined<br /> <br /> create_elf_fdpic_tables() does not correctly account the space for the<br /> AUX vector when an architecture has ELF_HWCAP2 defined. Prior to the<br /> commit 10e29251be0e ("binfmt_elf_fdpic: fix /proc//auxv") it<br /> resulted in the last entry of the AUX vector being set to zero, but with<br /> that change it results in a kernel BUG.<br /> <br /> Fix that by adding one to the number of AUXV entries (nitems) when<br /> ELF_HWCAP2 is defined.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2024

CVE-2024-46687

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()<br /> <br /> [BUG]<br /> There is an internal report that KASAN is reporting use-after-free, with<br /> the following backtrace:<br /> <br /> BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs]<br /> Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45<br /> CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]<br /> Call Trace:<br /> dump_stack_lvl+0x61/0x80<br /> print_address_description.constprop.0+0x5e/0x2f0<br /> print_report+0x118/0x216<br /> kasan_report+0x11d/0x1f0<br /> btrfs_check_read_bio+0xa68/0xb70 [btrfs]<br /> process_one_work+0xce0/0x12a0<br /> worker_thread+0x717/0x1250<br /> kthread+0x2e3/0x3c0<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Allocated by task 20917:<br /> kasan_save_stack+0x37/0x60<br /> kasan_save_track+0x10/0x30<br /> __kasan_slab_alloc+0x7d/0x80<br /> kmem_cache_alloc_noprof+0x16e/0x3e0<br /> mempool_alloc_noprof+0x12e/0x310<br /> bio_alloc_bioset+0x3f0/0x7a0<br /> btrfs_bio_alloc+0x2e/0x50 [btrfs]<br /> submit_extent_page+0x4d1/0xdb0 [btrfs]<br /> btrfs_do_readpage+0x8b4/0x12a0 [btrfs]<br /> btrfs_readahead+0x29a/0x430 [btrfs]<br /> read_pages+0x1a7/0xc60<br /> page_cache_ra_unbounded+0x2ad/0x560<br /> filemap_get_pages+0x629/0xa20<br /> filemap_read+0x335/0xbf0<br /> vfs_read+0x790/0xcb0<br /> ksys_read+0xfd/0x1d0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 20917:<br /> kasan_save_stack+0x37/0x60<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x50<br /> __kasan_slab_free+0x4b/0x60<br /> kmem_cache_free+0x214/0x5d0<br /> bio_free+0xed/0x180<br /> end_bbio_data_read+0x1cc/0x580 [btrfs]<br /> btrfs_submit_chunk+0x98d/0x1880 [btrfs]<br /> btrfs_submit_bio+0x33/0x70 [btrfs]<br /> submit_one_bio+0xd4/0x130 [btrfs]<br /> submit_extent_page+0x3ea/0xdb0 [btrfs]<br /> btrfs_do_readpage+0x8b4/0x12a0 [btrfs]<br /> btrfs_readahead+0x29a/0x430 [btrfs]<br /> read_pages+0x1a7/0xc60<br /> page_cache_ra_unbounded+0x2ad/0x560<br /> filemap_get_pages+0x629/0xa20<br /> filemap_read+0x335/0xbf0<br /> vfs_read+0x790/0xcb0<br /> ksys_read+0xfd/0x1d0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [CAUSE]<br /> Although I cannot reproduce the error, the report itself is good enough<br /> to pin down the cause.<br /> <br /> The call trace is the regular endio workqueue context, but the<br /> free-by-task trace is showing that during btrfs_submit_chunk() we<br /> already hit a critical error, and is calling btrfs_bio_end_io() to error<br /> out. And the original endio function called bio_put() to free the whole<br /> bio.<br /> <br /> This means a double freeing thus causing use-after-free, e.g.:<br /> <br /> 1. Enter btrfs_submit_bio() with a read bio<br /> The read bio length is 128K, crossing two 64K stripes.<br /> <br /> 2. The first run of btrfs_submit_chunk()<br /> <br /> 2.1 Call btrfs_map_block(), which returns 64K<br /> 2.2 Call btrfs_split_bio()<br /> Now there are two bios, one referring to the first 64K, the other<br /> referring to the second 64K.<br /> 2.3 The first half is submitted.<br /> <br /> 3. The second run of btrfs_submit_chunk()<br /> <br /> 3.1 Call btrfs_map_block(), which by somehow failed<br /> Now we call btrfs_bio_end_io() to handle the error<br /> <br /> 3.2 btrfs_bio_end_io() calls the original endio function<br /> Which is end_bbio_data_read(), and it calls bio_put() for the<br /> original bio.<br /> <br /> Now the original bio is freed.<br /> <br /> 4. The submitted first 64K bio finished<br /> Now we call into btrfs_check_read_bio() and tries to advance the bio<br /> iter.<br /> But since the original bio (thus its iter) is already freed, we<br /> trigger the above use-after free.<br /> <br /> And even if the memory is not poisoned/corrupted, we will later call<br /> the original endio function, causing a double freeing.<br /> <br /> [FIX]<br /> Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(),<br /> which has the extra check on split bios and do the pr<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
14/09/2024

CVE-2024-46688

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix out-of-bound access when z_erofs_gbuf_growsize() partially fails<br /> <br /> If z_erofs_gbuf_growsize() partially fails on a global buffer due to<br /> memory allocation failure or fault injection (as reported by syzbot [1]),<br /> new pages need to be freed by comparing to the existing pages to avoid<br /> memory leaks.<br /> <br /> However, the old gbuf-&gt;pages[] array may not be large enough, which can<br /> lead to null-ptr-deref or out-of-bound access.<br /> <br /> Fix this by checking against gbuf-&gt;nrpages in advance.<br /> <br /> [1] https://lore.kernel.org/r/000000000000f7b96e062018c6e3@google.com
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2024

CVE-2024-46690

Publication date:
13/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfsd4_deleg_getattr_conflict in presence of third party lease<br /> <br /> It is not safe to dereference fl-&gt;c.flc_owner without first confirming<br /> fl-&gt;fl_lmops is the expected manager. nfsd4_deleg_getattr_conflict()<br /> tests fl_lmops but largely ignores the result and assumes that flc_owner<br /> is an nfs4_delegation anyway. This is wrong.<br /> <br /> With this patch we restore the "!= &amp;nfsd_lease_mng_ops" case to behave<br /> as it did before the change mentioned below. This is the same as the<br /> current code, but without any reference to a possible delegation.
Severity CVSS v4.0: Pending analysis
Last modification:
20/09/2024