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

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: Fix out-of-bounds read in LDT setup<br /> <br /> syscall_stub_data() expects the data_count parameter to be the number of<br /> longs, not bytes.<br /> <br /> ==================================================================<br /> BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0<br /> Read of size 128 at addr 000000006411f6f0 by task swapper/1<br /> <br /> CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18<br /> Call Trace:<br /> show_stack.cold+0x166/0x2a7<br /> __dump_stack+0x3a/0x43<br /> dump_stack_lvl+0x1f/0x27<br /> print_report.cold+0xdb/0xf81<br /> kasan_report+0x119/0x1f0<br /> kasan_check_range+0x3a3/0x440<br /> memcpy+0x52/0x140<br /> syscall_stub_data+0x70/0xe0<br /> write_ldt_entry+0xac/0x190<br /> init_new_ldt+0x515/0x960<br /> init_new_context+0x2c4/0x4d0<br /> mm_init.constprop.0+0x5ed/0x760<br /> mm_alloc+0x118/0x170<br /> 0x60033f48<br /> do_one_initcall+0x1d7/0x860<br /> 0x60003e7b<br /> kernel_init+0x6e/0x3d4<br /> new_thread_handler+0x1e7/0x2c0<br /> <br /> The buggy address belongs to stack of task swapper/1<br /> and is located at offset 64 in frame:<br /> init_new_ldt+0x0/0x960<br /> <br /> This frame has 2 objects:<br /> [32, 40) &amp;#39;addr&amp;#39;<br /> [64, 80) &amp;#39;desc&amp;#39;<br /> ==================================================================
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2022-49400

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t set mddev private to NULL in raid0 pers-&gt;free<br /> <br /> In normal stop process, it does like this:<br /> do_md_stop<br /> |<br /> __md_stop (pers-&gt;free(); mddev-&gt;private=NULL)<br /> |<br /> md_free (free mddev)<br /> __md_stop sets mddev-&gt;private to NULL after pers-&gt;free. The raid device<br /> will be stopped and mddev memory is free. But in reshape, it doesn&amp;#39;t<br /> free the mddev and mddev will still be used in new raid.<br /> <br /> In reshape, it first sets mddev-&gt;private to new_pers and then runs<br /> old_pers-&gt;free(). Now raid0 sets mddev-&gt;private to NULL in raid0_free.<br /> The new raid can&amp;#39;t work anymore. It will panic when dereference<br /> mddev-&gt;private because of NULL pointer dereference.<br /> <br /> It can panic like this:<br /> [63010.814972] kernel BUG at drivers/md/raid10.c:928!<br /> [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1<br /> [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020<br /> [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10]<br /> [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246<br /> [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000<br /> [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800<br /> [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000<br /> [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200<br /> [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003<br /> [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000<br /> [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0<br /> [63010.927363] Call Trace:<br /> [63010.929822] ? bio_reset+0xe/0x40<br /> [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10]<br /> [63010.938629] raid10_sync_request+0x756/0x1610 [raid10]<br /> [63010.943770] md_do_sync.cold+0x3e4/0x94c<br /> [63010.947698] md_thread+0xab/0x160<br /> [63010.951024] ? md_write_inc+0x50/0x50<br /> [63010.954688] kthread+0x149/0x170<br /> [63010.957923] ? set_kthread_struct+0x40/0x40<br /> [63010.962107] ret_from_fork+0x22/0x30<br /> <br /> Removing the code that sets mddev-&gt;private to NULL in raid0 can fix<br /> problem.
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2022-49390

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: fix UAF bug for real_dev<br /> <br /> Create a new macsec device but not get reference to real_dev. That can<br /> not ensure that real_dev is freed after macsec. That will trigger the<br /> UAF bug for real_dev as following:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662<br /> Call Trace:<br /> ...<br /> macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662<br /> dev_get_iflink+0x73/0xe0 net/core/dev.c:637<br /> default_operstate net/core/link_watch.c:42 [inline]<br /> rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54<br /> linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161<br /> <br /> Allocated by task 22209:<br /> ...<br /> alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549<br /> rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235<br /> veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748<br /> <br /> Freed by task 8:<br /> ...<br /> kfree+0xd6/0x4d0 mm/slub.c:4552<br /> kvfree+0x42/0x50 mm/util.c:615<br /> device_release+0x9f/0x240 drivers/base/core.c:2229<br /> kobject_cleanup lib/kobject.c:673 [inline]<br /> kobject_release lib/kobject.c:704 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x1c8/0x540 lib/kobject.c:721<br /> netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327<br /> <br /> After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")<br /> and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we<br /> can add dev_hold_track() in macsec_dev_init() and dev_put_track() in<br /> macsec_free_netdev() to fix the problem.
Severity CVSS v4.0: Pending analysis
Last modification:
25/03/2025

CVE-2022-49385

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver: base: fix UAF when driver_attach failed<br /> <br /> When driver_attach(drv); failed, the driver_private will be freed.<br /> But it has been added to the bus, which caused a UAF.<br /> <br /> To fix it, we need to delete it from the bus when failed.
Severity CVSS v4.0: Pending analysis
Last modification:
25/03/2025

CVE-2022-49388

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: ubi_create_volume: Fix use-after-free when volume creation failed<br /> <br /> There is an use-after-free problem for &amp;#39;eba_tbl&amp;#39; in ubi_create_volume()&amp;#39;s<br /> error handling path:<br /> <br /> ubi_eba_replace_table(vol, eba_tbl)<br /> vol-&gt;eba_tbl = tbl<br /> out_mapping:<br /> ubi_eba_destroy_table(eba_tbl) // Free &amp;#39;eba_tbl&amp;#39;<br /> out_unlock:<br /> put_device(&amp;vol-&gt;dev)<br /> vol_release<br /> kfree(tbl-&gt;entries) // UAF<br /> <br /> Fix it by removing redundant &amp;#39;eba_tbl&amp;#39; releasing.<br /> Fetch a reproducer in [Link].
Severity CVSS v4.0: Pending analysis
Last modification:
25/03/2025

CVE-2022-49393

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix list iterator in fastrpc_req_mem_unmap_impl<br /> <br /> This is another instance of incorrect use of list iterator and<br /> checking it for NULL.<br /> <br /> The list iterator value &amp;#39;map&amp;#39; will *always* be set and non-NULL<br /> by list_for_each_entry(), so it is incorrect to assume that the<br /> iterator value will be NULL if the list is empty (in this case, the<br /> check &amp;#39;if (!map) {&amp;#39; will always be false and never exit as expected).<br /> <br /> To fix the bug, use a new variable &amp;#39;iter&amp;#39; as the list iterator,<br /> while use the original variable &amp;#39;map&amp;#39; as a dedicated pointer to<br /> point to the found element.<br /> <br /> Without this patch, Kernel crashes with below trace:<br /> <br /> Unable to handle kernel access to user memory outside uaccess routines<br /> at virtual address 0000ffff7fb03750<br /> ...<br /> Call trace:<br /> fastrpc_map_create+0x70/0x290 [fastrpc]<br /> fastrpc_req_mem_map+0xf0/0x2dc [fastrpc]<br /> fastrpc_device_ioctl+0x138/0xc60 [fastrpc]<br /> __arm64_sys_ioctl+0xa8/0xec<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0xd4/0xfc<br /> do_el0_svc+0x28/0x90<br /> el0_svc+0x3c/0x130<br /> el0t_64_sync_handler+0xa4/0x130<br /> el0t_64_sync+0x18c/0x190<br /> Code: 14000016 f94000a5 eb05029f 54000260 (b94018a6)<br /> ---[ end trace 0000000000000000 ]---
Severity CVSS v4.0: Pending analysis
Last modification:
26/02/2025

CVE-2022-49394

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iolatency: Fix inflight count imbalances and IO hangs on offline<br /> <br /> iolatency needs to track the number of inflight IOs per cgroup. As this<br /> tracking can be expensive, it is disabled when no cgroup has iolatency<br /> configured for the device. To ensure that the inflight counters stay<br /> balanced, iolatency_set_limit() freezes the request_queue while manipulating<br /> the enabled counter, which ensures that no IO is in flight and thus all<br /> counters are zero.<br /> <br /> Unfortunately, iolatency_set_limit() isn&amp;#39;t the only place where the enabled<br /> counter is manipulated. iolatency_pd_offline() can also dec the counter and<br /> trigger disabling. As this disabling happens without freezing the q, this<br /> can easily happen while some IOs are in flight and thus leak the counts.<br /> <br /> This can be easily demonstrated by turning on iolatency on an one empty<br /> cgroup while IOs are in flight in other cgroups and then removing the<br /> cgroup. Note that iolatency shouldn&amp;#39;t have been enabled elsewhere in the<br /> system to ensure that removing the cgroup disables iolatency for the whole<br /> device.<br /> <br /> The following keeps flipping on and off iolatency on sda:<br /> <br /> echo +io &gt; /sys/fs/cgroup/cgroup.subtree_control<br /> while true; do<br /> mkdir -p /sys/fs/cgroup/test<br /> echo &amp;#39;8:0 target=100000&amp;#39; &gt; /sys/fs/cgroup/test/io.latency<br /> sleep 1<br /> rmdir /sys/fs/cgroup/test<br /> sleep 1<br /> done<br /> <br /> and there&amp;#39;s concurrent fio generating direct rand reads:<br /> <br /> fio --name test --filename=/dev/sda --direct=1 --rw=randread \<br /> --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k<br /> <br /> while monitoring with the following drgn script:<br /> <br /> while True:<br /> for css in css_for_each_descendant_pre(prog[&amp;#39;blkcg_root&amp;#39;].css.address_of_()):<br /> for pos in hlist_for_each(container_of(css, &amp;#39;struct blkcg&amp;#39;, &amp;#39;css&amp;#39;).blkg_list):<br /> blkg = container_of(pos, &amp;#39;struct blkcg_gq&amp;#39;, &amp;#39;blkcg_node&amp;#39;)<br /> pd = blkg.pd[prog[&amp;#39;blkcg_policy_iolatency&amp;#39;].plid]<br /> if pd.value_() == 0:<br /> continue<br /> iolat = container_of(pd, &amp;#39;struct iolatency_grp&amp;#39;, &amp;#39;pd&amp;#39;)<br /> inflight = iolat.rq_wait.inflight.counter.value_()<br /> if inflight:<br /> print(f&amp;#39;inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} &amp;#39;<br /> f&amp;#39;{cgroup_path(css.cgroup).decode("utf-8")}&amp;#39;)<br /> time.sleep(1)<br /> <br /> The monitoring output looks like the following:<br /> <br /> inflight=1 sda /user.slice<br /> inflight=1 sda /user.slice<br /> ...<br /> inflight=14 sda /user.slice<br /> inflight=13 sda /user.slice<br /> inflight=17 sda /user.slice<br /> inflight=15 sda /user.slice<br /> inflight=18 sda /user.slice<br /> inflight=17 sda /user.slice<br /> inflight=20 sda /user.slice<br /> inflight=19 sda /user.slice
Severity CVSS v4.0: Pending analysis
Last modification:
26/02/2025

CVE-2022-49384

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix double free of io_acct_set bioset<br /> <br /> Now io_acct_set is alloc and free in personality. Remove the codes that<br /> free io_acct_set in md_free and md_stop.
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2022-49386

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don&amp;#39;t release<br /> the refcount in error case.<br /> Add missing of_node_put() to avoid refcount leak.
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2022-49387

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: rzg2l_wdt: Fix 32bit overflow issue<br /> <br /> The value of timer_cycle_us can be 0 due to 32bit overflow.<br /> For eg:- If we assign the counter value "0xfff" for computing<br /> maxval.<br /> <br /> This patch fixes this issue by appending ULL to 1024, so that<br /> it is promoted to 64bit.<br /> <br /> This patch also fixes the warning message, &amp;#39;watchdog: Invalid min and<br /> max timeout values, resetting to 0!&amp;#39;.
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2022-49389

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usbip: fix a refcount leak in stub_probe()<br /> <br /> usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails<br /> after that, usb_put_dev() needs to be called to release the reference.<br /> <br /> Fix this by moving usb_put_dev() to sdev_free error path handling.<br /> <br /> Find this by code review.
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025

CVE-2022-49391

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: mtk_scp: Fix a potential double free<br /> <br /> &amp;#39;scp-&gt;rproc&amp;#39; is allocated using devm_rproc_alloc(), so there is no need<br /> to free it explicitly in the remove function.
Severity CVSS v4.0: Pending analysis
Last modification:
17/04/2025