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

Publication date:
28/04/2024
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2024-33891. Reason: This candidate is a reservation duplicate of CVE-2024-33891. Notes: All CVE users should reference CVE-2024-33891 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
Severity CVSS v4.0: Pending analysis
Last modification:
28/04/2024

CVE-2024-33883

Publication date:
28/04/2024
The ejs (aka Embedded JavaScript templates) package before 3.1.10 for Node.js lacks certain pollution protection.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-48664

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix hang during unmount when stopping a space reclaim worker<br /> <br /> Often when running generic/562 from fstests we can hang during unmount,<br /> resulting in a trace like this:<br /> <br /> Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00<br /> Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds.<br /> Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1<br /> Sep 07 11:55:32 debian9 kernel: "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000<br /> Sep 07 11:55:32 debian9 kernel: Call Trace:<br /> Sep 07 11:55:32 debian9 kernel: <br /> Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0<br /> Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70<br /> Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0<br /> Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130<br /> Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0<br /> Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420<br /> Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0<br /> Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200<br /> Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0<br /> Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530<br /> Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140<br /> Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30<br /> Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0<br /> Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs]<br /> Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170<br /> Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs]<br /> Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0<br /> Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120<br /> Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30<br /> Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs]<br /> Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0<br /> Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160<br /> Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0<br /> Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0<br /> Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40<br /> Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90<br /> Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7<br /> Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6<br /> Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7<br /> Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0<br /> Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570<br /> Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000<br /> Sep 07 11:55:32 debian9 kernel: <br /> <br /> What happens is the following:<br /> <br /> 1) The cleaner kthread tries to start a transaction to delete an unused<br /> block group, but the metadata reservation can not be satisfied right<br /> away, so a reservation ticket is created and it starts the async<br /> metadata reclaim task (fs_info-&gt;async_reclaim_work);<br /> <br /> 2) Writeback for all the filler inodes with an i_size of 2K starts<br /> (generic/562 creates a lot of 2K files with the goal of filling<br /> metadata space). We try to create an inline extent for them, but we<br /> fail when trying to insert the inline extent with -ENOSPC (at<br /> cow_file_range_inline()) - since this is not critical, we fallback<br /> to non-inline mode (back to cow_file_range()), reserve extents<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
26/09/2025

CVE-2022-48665

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix overflow for large capacity partition<br /> <br /> Using int type for sector index, there will be overflow in a large<br /> capacity partition.<br /> <br /> For example, if storage with sector size of 512 bytes and partition<br /> capacity is larger than 2TB, there will be overflow.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2022-48666

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix a use-after-free<br /> <br /> There are two .exit_cmd_priv implementations. Both implementations use<br /> resources associated with the SCSI host. Make sure that these resources are<br /> still available when .exit_cmd_priv is called by waiting inside<br /> scsi_remove_host() until the tag set has been freed.<br /> <br /> This commit fixes the following use-after-free:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]<br /> Read of size 8 at addr ffff888100337000 by task multipathd/16727<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_report.cold+0x5e/0x5db<br /> kasan_report+0xab/0x120<br /> srp_exit_cmd_priv+0x27/0xd0 [ib_srp]<br /> scsi_mq_exit_request+0x4d/0x70<br /> blk_mq_free_rqs+0x143/0x410<br /> __blk_mq_free_map_and_rqs+0x6e/0x100<br /> blk_mq_free_tag_set+0x2b/0x160<br /> scsi_host_dev_release+0xf3/0x1a0<br /> device_release+0x54/0xe0<br /> kobject_put+0xa5/0x120<br /> device_release+0x54/0xe0<br /> kobject_put+0xa5/0x120<br /> scsi_device_dev_release_usercontext+0x4c1/0x4e0<br /> execute_in_process_context+0x23/0x90<br /> device_release+0x54/0xe0<br /> kobject_put+0xa5/0x120<br /> scsi_disk_release+0x3f/0x50<br /> device_release+0x54/0xe0<br /> kobject_put+0xa5/0x120<br /> disk_release+0x17f/0x1b0<br /> device_release+0x54/0xe0<br /> kobject_put+0xa5/0x120<br /> dm_put_table_device+0xa3/0x160 [dm_mod]<br /> dm_put_device+0xd0/0x140 [dm_mod]<br /> free_priority_group+0xd8/0x110 [dm_multipath]<br /> free_multipath+0x94/0xe0 [dm_multipath]<br /> dm_table_destroy+0xa2/0x1e0 [dm_mod]<br /> __dm_destroy+0x196/0x350 [dm_mod]<br /> dev_remove+0x10c/0x160 [dm_mod]<br /> ctl_ioctl+0x2c2/0x590 [dm_mod]<br /> dm_ctl_ioctl+0x5/0x10 [dm_mod]<br /> __x64_sys_ioctl+0xb4/0xf0<br /> dm_ctl_ioctl+0x5/0x10 [dm_mod]<br /> __x64_sys_ioctl+0xb4/0xf0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0
Severity CVSS v4.0: Pending analysis
Last modification:
20/03/2025

CVE-2022-48667

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: fix temporary data corruption in insert range<br /> <br /> insert range doesn&amp;#39;t discard the affected cached region<br /> so can risk temporarily corrupting file data.<br /> <br /> Also includes some minor cleanup (avoiding rereading<br /> inode size repeatedly unnecessarily) to make it clearer.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2022-48668

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: fix temporary data corruption in collapse range<br /> <br /> collapse range doesn&amp;#39;t discard the affected cached region<br /> so can risk temporarily corrupting the file data. This<br /> fixes xfstest generic/031<br /> <br /> I also decided to merge a minor cleanup to this into the same patch<br /> (avoiding rereading inode size repeatedly unnecessarily) to make it<br /> clearer.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2024-25050

Publication date:
28/04/2024
IBM i 7.2, 7.3, 7.4, 7.5 and IBM Rational Development Studio for i 7.2, 7.3, 7.4, 7.5 networking and compiler infrastructure could allow a local user to gain elevated privileges due to an unqualified library call. A malicious actor could cause user-controlled code to run with administrator privileges. IBM X-Force ID: 283242.
Severity CVSS v4.0: Pending analysis
Last modification:
13/08/2025

CVE-2022-48642

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()<br /> <br /> It seems to me that percpu memory for chain stats started leaking since<br /> commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to<br /> hardware priority") when nft_chain_offload_priority() returned an error.
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2025

CVE-2022-48643

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain()<br /> <br /> syzbot is reporting underflow of nft_counters_enabled counter at<br /> nf_tables_addchain() [1], for commit 43eb8949cfdffa76 ("netfilter:<br /> nf_tables: do not leave chain stats enabled on error") missed that<br /> nf_tables_chain_destroy() after nft_basechain_init() in the error path of<br /> nf_tables_addchain() decrements the counter because nft_basechain_init()<br /> makes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag.<br /> <br /> Increment the counter immediately after returning from<br /> nft_basechain_init().
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2022-48644

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: avoid disabling offload when it was never enabled<br /> <br /> In an incredibly strange API design decision, qdisc-&gt;destroy() gets<br /> called even if qdisc-&gt;init() never succeeded, not exclusively since<br /> commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"),<br /> but apparently also earlier (in the case of qdisc_create_dflt()).<br /> <br /> The taprio qdisc does not fully acknowledge this when it attempts full<br /> offload, because it starts off with q-&gt;flags = TAPRIO_FLAGS_INVALID in<br /> taprio_init(), then it replaces q-&gt;flags with TCA_TAPRIO_ATTR_FLAGS<br /> parsed from netlink (in taprio_change(), tail called from taprio_init()).<br /> <br /> But in taprio_destroy(), we call taprio_disable_offload(), and this<br /> determines what to do based on FULL_OFFLOAD_IS_ENABLED(q-&gt;flags).<br /> <br /> But looking at the implementation of FULL_OFFLOAD_IS_ENABLED()<br /> (a bitwise check of bit 1 in q-&gt;flags), it is invalid to call this macro<br /> on q-&gt;flags when it contains TAPRIO_FLAGS_INVALID, because that is set<br /> to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on<br /> an invalid set of flags.<br /> <br /> As a result, it is possible to crash the kernel if user space forces an<br /> error between setting q-&gt;flags = TAPRIO_FLAGS_INVALID, and the calling<br /> of taprio_enable_offload(). This is because drivers do not expect the<br /> offload to be disabled when it was never enabled.<br /> <br /> The error that we force here is to attach taprio as a non-root qdisc,<br /> but instead as child of an mqprio root qdisc:<br /> <br /> $ tc qdisc add dev swp0 root handle 1: \<br /> mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \<br /> queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0<br /> $ tc qdisc replace dev swp0 parent 1:1 \<br /> taprio num_tc 8 map 0 1 2 3 4 5 6 7 \<br /> queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \<br /> sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \<br /> flags 0x0 clockid CLOCK_TAI<br /> Unable to handle kernel paging request at virtual address fffffffffffffff8<br /> [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> Call trace:<br /> taprio_dump+0x27c/0x310<br /> vsc9959_port_setup_tc+0x1f4/0x460<br /> felix_port_setup_tc+0x24/0x3c<br /> dsa_slave_setup_tc+0x54/0x27c<br /> taprio_disable_offload.isra.0+0x58/0xe0<br /> taprio_destroy+0x80/0x104<br /> qdisc_create+0x240/0x470<br /> tc_modify_qdisc+0x1fc/0x6b0<br /> rtnetlink_rcv_msg+0x12c/0x390<br /> netlink_rcv_skb+0x5c/0x130<br /> rtnetlink_rcv+0x1c/0x2c<br /> <br /> Fix this by keeping track of the operations we made, and undo the<br /> offload only if we actually did it.<br /> <br /> I&amp;#39;ve added "bool offloaded" inside a 4 byte hole between "int clockid"<br /> and "atomic64_t picos_per_byte". Now the first cache line looks like<br /> below:<br /> <br /> $ pahole -C taprio_sched net/sched/sch_taprio.o<br /> struct taprio_sched {<br /> struct Qdisc * * qdiscs; /* 0 8 */<br /> struct Qdisc * root; /* 8 8 */<br /> u32 flags; /* 16 4 */<br /> enum tk_offsets tk_offset; /* 20 4 */<br /> int clockid; /* 24 4 */<br /> bool offloaded; /* 28 1 */<br /> <br /> /* XXX 3 bytes hole, try to pack */<br /> <br /> atomic64_t picos_per_byte; /* 32 0 */<br /> <br /> /* XXX 8 bytes hole, try to pack */<br /> <br /> spinlock_t current_entry_lock; /* 40 0 */<br /> <br /> /* XXX 8 bytes hole, try to pack */<br /> <br /> struct sched_entry * current_entry; /* 48 8 */<br /> struct sched_gate_list * oper_sched; /* 56 8 */<br /> /* --- cacheline 1 boundary (64 bytes) --- */
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2022-48645

Publication date:
28/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: deny offload of tc-based TSN features on VF interfaces<br /> <br /> TSN features on the ENETC (taprio, cbs, gate, police) are configured<br /> through a mix of command BD ring messages and port registers:<br /> enetc_port_rd(), enetc_port_wr().<br /> <br /> Port registers are a region of the ENETC memory map which are only<br /> accessible from the PCIe Physical Function. They are not accessible from<br /> the Virtual Functions.<br /> <br /> Moreover, attempting to access these registers crashes the kernel:<br /> <br /> $ echo 1 &gt; /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs<br /> pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001<br /> fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15<br /> fsl_enetc_vf 0000:00:01.0: enabling device (0000 -&gt; 0002)<br /> fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0<br /> $ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \<br /> queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \<br /> sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2<br /> Unable to handle kernel paging request at virtual address ffff800009551a08<br /> Internal error: Oops: 96000007 [#1] PREEMPT SMP<br /> pc : enetc_setup_tc_taprio+0x170/0x47c<br /> lr : enetc_setup_tc_taprio+0x16c/0x47c<br /> Call trace:<br /> enetc_setup_tc_taprio+0x170/0x47c<br /> enetc_setup_tc+0x38/0x2dc<br /> taprio_change+0x43c/0x970<br /> taprio_init+0x188/0x1e0<br /> qdisc_create+0x114/0x470<br /> tc_modify_qdisc+0x1fc/0x6c0<br /> rtnetlink_rcv_msg+0x12c/0x390<br /> <br /> Split enetc_setup_tc() into separate functions for the PF and for the<br /> VF drivers. Also remove enetc_qos.o from being included into<br /> enetc-vf.ko, since it serves absolutely no purpose there.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025