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-2022-50535

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix potential null-deref in dm_resume<br /> <br /> [Why]<br /> Fixing smatch error:<br /> dm_resume() error: we previously assumed &amp;#39;aconnector-&gt;dc_link&amp;#39; could be null<br /> <br /> [How]<br /> Check if dc_link null at the beginning of the loop,<br /> so further checks can be dropped.
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50534

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm thin: Use last transaction&amp;#39;s pmd-&gt;root when commit failed<br /> <br /> Recently we found a softlock up problem in dm thin pool btree lookup<br /> code due to corrupted metadata:<br /> <br /> Kernel panic - not syncing: softlockup: hung tasks<br /> CPU: 7 PID: 2669225 Comm: kworker/u16:3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: dm-thin do_worker [dm_thin_pool]<br /> Call Trace:<br /> <br /> dump_stack+0x9c/0xd3<br /> panic+0x35d/0x6b9<br /> watchdog_timer_fn.cold+0x16/0x25<br /> __run_hrtimer+0xa2/0x2d0<br /> <br /> RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]<br /> __bufio_new+0x11f/0x4f0 [dm_bufio]<br /> new_read+0xa3/0x1e0 [dm_bufio]<br /> dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]<br /> ro_step+0x63/0x100 [dm_persistent_data]<br /> btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]<br /> dm_btree_lookup+0x16f/0x210 [dm_persistent_data]<br /> dm_thin_find_block+0x12c/0x210 [dm_thin_pool]<br /> __process_bio_read_only+0xc5/0x400 [dm_thin_pool]<br /> process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]<br /> process_one_work+0x3c5/0x730<br /> <br /> Following process may generate a broken btree mixed with fresh and<br /> stale btree nodes, which could get dm thin trapped in an infinite loop<br /> while looking up data block:<br /> Transaction 1: pmd-&gt;root = A, A-&gt;B-&gt;C // One path in btree<br /> pmd-&gt;root = X, X-&gt;Y-&gt;Z // Copy-up<br /> Transaction 2: X,Z is updated on disk, Y write failed.<br /> // Commit failed, dm thin becomes read-only.<br /> process_bio_read_only<br /> dm_thin_find_block<br /> __find_block<br /> dm_btree_lookup(pmd-&gt;root)<br /> The pmd-&gt;root points to a broken btree, Y may contain stale node<br /> pointing to any block, for example X, which gets dm thin trapped into<br /> a dead loop while looking up Z.<br /> <br /> Fix this by setting pmd-&gt;root in __open_metadata(), so that dm thin<br /> will use the last transaction&amp;#39;s pmd-&gt;root if commit failed.<br /> <br /> Fetch a reproducer in [Link].<br /> <br /> Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50522

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mcb: mcb-parse: fix error handing in chameleon_parse_gdd()<br /> <br /> If mcb_device_register() returns error in chameleon_parse_gdd(), the refcount<br /> of bus and device name are leaked. Fix this by calling put_device() to give up<br /> the reference, so they can be released in mcb_release_dev() and kobject_cleanup().
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50524

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Check return value after calling platform_get_resource()<br /> <br /> platform_get_resource() may return NULL pointer, we need check its<br /> return value to avoid null-ptr-deref in resource_size().
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50523

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: rockchip: Fix memory leak in rockchip_clk_register_pll()<br /> <br /> If clk_register() fails, @pll-&gt;rate_table may have allocated memory by<br /> kmemdup(), so it needs to be freed, otherwise will cause memory leak<br /> issue, this patch fixes it.
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50526

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: fix memory corruption with too many bridges<br /> <br /> Add the missing sanity check on the bridge counter to avoid corrupting<br /> data beyond the fixed-sized bridge array in case there are ever more<br /> than eight bridges.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502664/
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50525

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe()<br /> <br /> The fsl_pamu_probe() returns directly when create_csd() failed, leaving<br /> irq and memories unreleased.<br /> Fix by jumping to error if create_csd() returns error.
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50527

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix size validation for non-exclusive domains (v4)<br /> <br /> Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for the<br /> requested memory exists, else we get a kernel oops when dereferencing "man".<br /> <br /> v2: Make the patch standalone, i.e. not dependent on local patches.<br /> v3: Preserve old behaviour and just check that the manager pointer is not<br /> NULL.<br /> v4: Complain if GTT domain requested and it is uninitialized--most likely a<br /> bug.
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50528

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix memory leakage<br /> <br /> This patch fixes potential memory leakage and seg fault<br /> in _gpuvm_import_dmabuf() function
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50529

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> test_firmware: fix memory leak in test_firmware_init()<br /> <br /> When misc_register() failed in test_firmware_init(), the memory pointed<br /> by test_fw_config-&gt;name is not released. The memory leak information is<br /> as follows:<br /> unreferenced object 0xffff88810a34cb00 (size 32):<br /> comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)<br /> hex dump (first 32 bytes):<br /> 74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi<br /> 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x4b/0xc0<br /> [] kstrndup+0x46/0xc0<br /> [] __test_firmware_config_init+0x29/0x380 [test_firmware]<br /> [] 0xffffffffa040f068<br /> [] do_one_initcall+0x141/0x780<br /> [] do_init_module+0x1c3/0x630<br /> [] load_module+0x623e/0x76a0<br /> [] __do_sys_finit_module+0x181/0x240<br /> [] do_syscall_64+0x39/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50515

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue()<br /> <br /> If construction of the array of work queues to handle hpd_rx_irq offload<br /> work fails, we need to unwind. Destroy all the created workqueues and<br /> the allocated memory for the hpd_rx_irq_offload_work_queue struct array.
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026

CVE-2022-50517

Publication date:
07/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: do not clobber swp_entry_t during THP split<br /> <br /> The following has been observed when running stressng mmap since commit<br /> b653db77350c ("mm: Clear page-&gt;private when splitting or migrating a page")<br /> <br /> watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]<br /> CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374<br /> Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016<br /> RIP: 0010:xas_descend+0x28/0x80<br /> Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2<br /> RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246<br /> RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002<br /> RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0<br /> RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0<br /> R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000<br /> R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88<br /> FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> xas_load+0x3a/0x50<br /> __filemap_get_folio+0x80/0x370<br /> ? put_swap_page+0x163/0x360<br /> pagecache_get_page+0x13/0x90<br /> __try_to_reclaim_swap+0x50/0x190<br /> scan_swap_map_slots+0x31e/0x670<br /> get_swap_pages+0x226/0x3c0<br /> folio_alloc_swap+0x1cc/0x240<br /> add_to_swap+0x14/0x70<br /> shrink_page_list+0x968/0xbc0<br /> reclaim_page_list+0x70/0xf0<br /> reclaim_pages+0xdd/0x120<br /> madvise_cold_or_pageout_pte_range+0x814/0xf30<br /> walk_pgd_range+0x637/0xa30<br /> __walk_page_range+0x142/0x170<br /> walk_page_range+0x146/0x170<br /> madvise_pageout+0xb7/0x280<br /> ? asm_common_interrupt+0x22/0x40<br /> madvise_vma_behavior+0x3b7/0xac0<br /> ? find_vma+0x4a/0x70<br /> ? find_vma+0x64/0x70<br /> ? madvise_vma_anon_name+0x40/0x40<br /> madvise_walk_vmas+0xa6/0x130<br /> do_madvise+0x2f4/0x360<br /> __x64_sys_madvise+0x26/0x30<br /> do_syscall_64+0x5b/0x80<br /> ? do_syscall_64+0x67/0x80<br /> ? syscall_exit_to_user_mode+0x17/0x40<br /> ? do_syscall_64+0x67/0x80<br /> ? syscall_exit_to_user_mode+0x17/0x40<br /> ? do_syscall_64+0x67/0x80<br /> ? do_syscall_64+0x67/0x80<br /> ? common_interrupt+0x8b/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The problem can be reproduced with the mmtests config<br /> config-workload-stressng-mmap. It does not always happen and when it<br /> triggers is variable but it has happened on multiple machines.<br /> <br /> The intent of commit b653db77350c patch was to avoid the case where<br /> PG_private is clear but folio-&gt;private is not-NULL. However, THP tail<br /> pages uses page-&gt;private for "swp_entry_t if folio_test_swapcache()" as<br /> stated in the documentation for struct folio. This patch only clobbers<br /> page-&gt;private for tail pages if the head page was not in swapcache and<br /> warns once if page-&gt;private had an unexpected value.
Severity CVSS v4.0: Pending analysis
Last modification:
17/03/2026