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

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: mqueue: fix possible memory leak in init_mqueue_fs()<br /> <br /> commit db7cfc380900 ("ipc: Free mq_sysctls if ipc namespace creation<br /> failed")<br /> <br /> Here&amp;#39;s a similar memory leak to the one fixed by the patch above.<br /> retire_mq_sysctls need to be called when init_mqueue_fs fails after<br /> setup_mq_sysctls.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50749

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acct: fix potential integer overflow in encode_comp_t()<br /> <br /> The integer overflow is descripted with following codes:<br /> &gt; 317 static comp_t encode_comp_t(u64 value)<br /> &gt; 318 {<br /> &gt; 319 int exp, rnd;<br /> ......<br /> &gt; 341 exp 343 return exp;<br /> &gt; 344 }<br /> <br /> Currently comp_t is defined as type of &amp;#39;__u16&amp;#39;, but the variable &amp;#39;exp&amp;#39; is<br /> type of &amp;#39;int&amp;#39;, so overflow would happen when variable &amp;#39;exp&amp;#39; in line 343 is<br /> greater than 65535.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50750

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel/panel-sitronix-st7701: Remove panel on DSI attach failure<br /> <br /> In case mipi_dsi_attach() fails, call drm_panel_remove() to<br /> avoid memory leak.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50751

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> configfs: fix possible memory leak in configfs_create_dir()<br /> <br /> kmemleak reported memory leaks in configfs_create_dir():<br /> <br /> unreferenced object 0xffff888009f6af00 (size 192):<br /> comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)<br /> backtrace:<br /> kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)<br /> new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)<br /> configfs_register_subsystem (fs/configfs/dir.c:1857)<br /> basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic<br /> do_one_initcall (init/main.c:1296)<br /> do_init_module (kernel/module/main.c:2455)<br /> ...<br /> <br /> unreferenced object 0xffff888003ba7180 (size 96):<br /> comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)<br /> backtrace:<br /> kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)<br /> configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)<br /> configfs_make_dirent (fs/configfs/dir.c:248)<br /> configfs_create_dir (fs/configfs/dir.c:296)<br /> configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)<br /> configfs_register_subsystem (fs/configfs/dir.c:1881)<br /> basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic<br /> do_one_initcall (init/main.c:1296)<br /> do_init_module (kernel/module/main.c:2455)<br /> ...<br /> <br /> This is because the refcount is not correct in configfs_make_dirent().<br /> For normal stage, the refcount is changing as:<br /> <br /> configfs_register_subsystem()<br /> configfs_create_dir()<br /> configfs_make_dirent()<br /> configfs_new_dirent() # set s_count = 1<br /> dentry-&gt;d_fsdata = configfs_get(sd); # s_count = 2<br /> ...<br /> configfs_unregister_subsystem()<br /> configfs_remove_dir()<br /> remove_dir()<br /> configfs_remove_dirent() # s_count = 1<br /> dput() ...<br /> *dentry_unlink_inode()*<br /> configfs_d_iput() # s_count = 0, release<br /> <br /> However, if we failed in configfs_create():<br /> <br /> configfs_register_subsystem()<br /> configfs_create_dir()<br /> configfs_make_dirent() # s_count = 2<br /> ...<br /> configfs_create() # fail<br /> -&gt;out_remove:<br /> configfs_remove_dirent(dentry)<br /> configfs_put(sd) # s_count = 1<br /> return PTR_ERR(inode);<br /> <br /> There is no inode in the error path, so the configfs_d_iput() is lost<br /> and makes sd and fragment memory leaked.<br /> <br /> To fix this, when we failed in configfs_create(), manually call<br /> configfs_put(sd) to keep the refcount correct.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50752

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: Remove unnecessary bio_put() in raid5_read_one_chunk()<br /> <br /> When running chunk-sized reads on disks with badblocks duplicate bio<br /> free/puts are observed:<br /> <br /> =============================================================================<br /> BUG bio-200 (Not tainted): Object already free<br /> -----------------------------------------------------------------------------<br /> Allocated in mempool_alloc_slab+0x17/0x20 age=3 cpu=2 pid=7504<br /> __slab_alloc.constprop.0+0x5a/0xb0<br /> kmem_cache_alloc+0x31e/0x330<br /> mempool_alloc_slab+0x17/0x20<br /> mempool_alloc+0x100/0x2b0<br /> bio_alloc_bioset+0x181/0x460<br /> do_mpage_readpage+0x776/0xd00<br /> mpage_readahead+0x166/0x320<br /> blkdev_readahead+0x15/0x20<br /> read_pages+0x13f/0x5f0<br /> page_cache_ra_unbounded+0x18d/0x220<br /> force_page_cache_ra+0x181/0x1c0<br /> page_cache_sync_ra+0x65/0xb0<br /> filemap_get_pages+0x1df/0xaf0<br /> filemap_read+0x1e1/0x700<br /> blkdev_read_iter+0x1e5/0x330<br /> vfs_read+0x42a/0x570<br /> Freed in mempool_free_slab+0x17/0x20 age=3 cpu=2 pid=7504<br /> kmem_cache_free+0x46d/0x490<br /> mempool_free_slab+0x17/0x20<br /> mempool_free+0x66/0x190<br /> bio_free+0x78/0x90<br /> bio_put+0x100/0x1a0<br /> raid5_make_request+0x2259/0x2450<br /> md_handle_request+0x402/0x600<br /> md_submit_bio+0xd9/0x120<br /> __submit_bio+0x11f/0x1b0<br /> submit_bio_noacct_nocheck+0x204/0x480<br /> submit_bio_noacct+0x32e/0xc70<br /> submit_bio+0x98/0x1a0<br /> mpage_readahead+0x250/0x320<br /> blkdev_readahead+0x15/0x20<br /> read_pages+0x13f/0x5f0<br /> page_cache_ra_unbounded+0x18d/0x220<br /> Slab 0xffffea000481b600 objects=21 used=0 fp=0xffff8881206d8940 flags=0x17ffffc0010201(locked|slab|head|node=0|zone=2|lastcpupid=0x1fffff)<br /> CPU: 0 PID: 34525 Comm: kworker/u24:2 Not tainted 6.0.0-rc2-localyes-265166-gf11c5343fa3f #143<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: raid5wq raid5_do_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5a/0x78<br /> dump_stack+0x10/0x16<br /> print_trailer+0x158/0x165<br /> object_err+0x35/0x50<br /> free_debug_processing.cold+0xb7/0xbe<br /> __slab_free+0x1ae/0x330<br /> kmem_cache_free+0x46d/0x490<br /> mempool_free_slab+0x17/0x20<br /> mempool_free+0x66/0x190<br /> bio_free+0x78/0x90<br /> bio_put+0x100/0x1a0<br /> mpage_end_io+0x36/0x150<br /> bio_endio+0x2fd/0x360<br /> md_end_io_acct+0x7e/0x90<br /> bio_endio+0x2fd/0x360<br /> handle_failed_stripe+0x960/0xb80<br /> handle_stripe+0x1348/0x3760<br /> handle_active_stripes.constprop.0+0x72a/0xaf0<br /> raid5_do_work+0x177/0x330<br /> process_one_work+0x616/0xb20<br /> worker_thread+0x2bd/0x6f0<br /> kthread+0x179/0x1b0<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> The double free is caused by an unnecessary bio_put() in the<br /> if(is_badblock(...)) error path in raid5_read_one_chunk().<br /> <br /> The error path was moved ahead of bio_alloc_clone() in c82aa1b76787c<br /> ("md/raid5: move checking badblock before clone bio in<br /> raid5_read_one_chunk"). The previous code checked and freed align_bio<br /> which required a bio_put. After the move that is no longer needed as<br /> raid_bio is returned to the control of the common io path which<br /> performs its own endio resulting in a double free on bad device blocks.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50734

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: core: Fix memleak in nvmem_register()<br /> <br /> dev_set_name will alloc memory for nvmem-&gt;dev.kobj.name in<br /> nvmem_register, when nvmem_validate_keepouts failed, nvmem&amp;#39;s<br /> memory will be freed and return, but nobody will free memory<br /> for nvmem-&gt;dev.kobj.name, there will be memleak, so moving<br /> nvmem_validate_keepouts() after device_register() and let<br /> the device core deal with cleaning name in error cases.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50735

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: do not run mt76u_status_worker if the device is not running<br /> <br /> Fix the following NULL pointer dereference avoiding to run<br /> mt76u_status_worker thread if the device is not running yet.<br /> <br /> KASAN: null-ptr-deref in range<br /> [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware<br /> name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> Workqueue: mt76 mt76u_tx_status_data<br /> RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0<br /> Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00<br /> 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <br /> b6<br /> 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7<br /> RSP: 0018:ffffc900005af988 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a<br /> RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c<br /> R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8<br /> R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28<br /> FS: 0000000000000000(0000) GS:ffff88811aa00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> mt76x02_send_tx_status+0x1d2/0xeb0<br /> mt76x02_tx_status_data+0x8e/0xd0<br /> mt76u_tx_status_data+0xe1/0x240<br /> process_one_work+0x92b/0x1460<br /> worker_thread+0x95/0xe00<br /> kthread+0x3a1/0x480<br /> ret_from_fork+0x1f/0x30<br /> Modules linked in:<br /> --[ end trace 8df5d20fc5040f65 ]--<br /> RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0<br /> Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00<br /> 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <br /> b6<br /> 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7<br /> RSP: 0018:ffffc900005af988 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a<br /> RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c<br /> R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8<br /> R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28<br /> FS: 0000000000000000(0000) GS:ffff88811aa00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> <br /> Moreover move stat_work schedule out of the for loop.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50736

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix immediate work request flush to completion queue<br /> <br /> Correctly set send queue element opcode during immediate work request<br /> flushing in post sendqueue operation, if the QP is in ERROR state.<br /> An undefined ocode value results in out-of-bounds access to an array<br /> for mapping the opcode between siw internal and RDMA core representation<br /> in work completion generation. It resulted in a KASAN BUG report<br /> of type &amp;#39;global-out-of-bounds&amp;#39; during NFSoRDMA testing.<br /> <br /> This patch further fixes a potential case of a malicious user which may<br /> write undefined values for completion queue elements status or opcode,<br /> if the CQ is memory mapped to user land. It avoids the same out-of-bounds<br /> access to arrays for status and opcode mapping as described above.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50737

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Validate index root when initialize NTFS security<br /> <br /> This enhances the sanity check for $SDH and $SII while initializing NTFS<br /> security, guarantees these index root are legit.<br /> <br /> [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243<br /> [ 162.460851]<br /> [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42<br /> [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 162.462609] Call Trace:<br /> [ 162.462954] <br /> [ 162.463276] dump_stack_lvl+0x49/0x63<br /> [ 162.463822] print_report.cold+0xf5/0x689<br /> [ 162.464608] ? unwind_get_return_address+0x3a/0x60<br /> [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.466975] kasan_report+0xa7/0x130<br /> [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0<br /> [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.468536] __asan_load2+0x68/0x90<br /> [ 162.468923] hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.469282] ? cmp_uints+0xe0/0xe0<br /> [ 162.469557] ? cmp_sdh+0x90/0x90<br /> [ 162.469864] ? ni_find_attr+0x214/0x300<br /> [ 162.470217] ? ni_load_mi+0x80/0x80<br /> [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.470931] ? ntfs_bread_run+0x190/0x190<br /> [ 162.471307] ? indx_get_root+0xe4/0x190<br /> [ 162.471556] ? indx_get_root+0x140/0x190<br /> [ 162.471833] ? indx_init+0x1e0/0x1e0<br /> [ 162.472069] ? fnd_clear+0x115/0x140<br /> [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100<br /> [ 162.472731] indx_find+0x184/0x470<br /> [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0<br /> [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0<br /> [ 162.474704] ? do_syscall_64+0x3b/0x90<br /> [ 162.474962] dir_search_u+0x196/0x2f0<br /> [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450<br /> [ 162.475661] ? ntfs_security_init+0x3d6/0x440<br /> [ 162.475906] ? is_sd_valid+0x180/0x180<br /> [ 162.476191] ntfs_extend_init+0x13f/0x2c0<br /> [ 162.476496] ? ntfs_fix_post_read+0x130/0x130<br /> [ 162.476861] ? iput.part.0+0x286/0x320<br /> [ 162.477325] ntfs_fill_super+0x11e0/0x1b50<br /> [ 162.477709] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.477970] ? vsprintf+0x20/0x20<br /> [ 162.478258] ? set_blocksize+0x95/0x150<br /> [ 162.478538] get_tree_bdev+0x232/0x370<br /> [ 162.478789] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.479038] ntfs_fs_get_tree+0x15/0x20<br /> [ 162.479374] vfs_get_tree+0x4c/0x130<br /> [ 162.479729] path_mount+0x654/0xfe0<br /> [ 162.480124] ? putname+0x80/0xa0<br /> [ 162.480484] ? finish_automount+0x2e0/0x2e0<br /> [ 162.480894] ? putname+0x80/0xa0<br /> [ 162.481467] ? kmem_cache_free+0x1c4/0x440<br /> [ 162.482280] ? putname+0x80/0xa0<br /> [ 162.482714] do_mount+0xd6/0xf0<br /> [ 162.483264] ? path_mount+0xfe0/0xfe0<br /> [ 162.484782] ? __kasan_check_write+0x14/0x20<br /> [ 162.485593] __x64_sys_mount+0xca/0x110<br /> [ 162.486024] do_syscall_64+0x3b/0x90<br /> [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.487141] RIP: 0033:0x7f9d374e948a<br /> [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5<br /> [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a<br /> [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0<br /> [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020<br /> [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0<br /> [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 162.493644] <br /> [ 162.493908]<br /> [ 162.494214] The buggy address belongs to the physical page:<br /> [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc<br /> [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000<br /> [ 162.498928] raw: 0000000000000000 0000000000240000 0<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50738

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-vdpa: fix an iotlb memory leak<br /> <br /> Before commit 3d5698793897 ("vhost-vdpa: introduce asid based IOTLB")<br /> we called vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1) during<br /> release to free all the resources allocated when processing user IOTLB<br /> messages through vhost_vdpa_process_iotlb_update().<br /> That commit changed the handling of IOTLB a bit, and we accidentally<br /> removed some code called during the release.<br /> <br /> We partially fixed this with commit 037d4305569a ("vhost-vdpa: call<br /> vhost_vdpa_cleanup during the release") but a potential memory leak is<br /> still there as showed by kmemleak if the application does not send<br /> VHOST_IOTLB_INVALIDATE or crashes:<br /> <br /> unreferenced object 0xffff888007fbaa30 (size 16):<br /> comm "blkio-bench", pid 914, jiffies 4294993521 (age 885.500s)<br /> hex dump (first 16 bytes):<br /> 40 73 41 07 80 88 ff ff 00 00 00 00 00 00 00 00 @sA.............<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x142/0x1c0<br /> [] vhost_vdpa_process_iotlb_msg+0x68c/0x901 [vhost_vdpa]<br /> [] vhost_chr_write_iter+0xc0/0x4a0 [vhost]<br /> [] vhost_vdpa_chr_write_iter+0x18/0x20 [vhost_vdpa]<br /> [] vfs_write+0x216/0x4b0<br /> [] ksys_write+0x71/0xf0<br /> [] __x64_sys_write+0x19/0x20<br /> [] do_syscall_64+0x3f/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Let&amp;#39;s fix this calling vhost_vdpa_iotlb_unmap() on the whole range in<br /> vhost_vdpa_remove_as(). We move that call before vhost_dev_cleanup()<br /> since we need a valid v-&gt;vdev.mm in vhost_vdpa_pa_unmap().<br /> vhost_iotlb_reset() call can be removed, since vhost_vdpa_iotlb_unmap()<br /> on the whole range removes all the entries.<br /> <br /> The kmemleak log reported was observed with a vDPA device that has `use_va`<br /> set to true (e.g. VDUSE). This patch has been tested with both types of<br /> devices.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50739

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add null pointer check for inode operations<br /> <br /> This adds a sanity check for the i_op pointer of the inode which is<br /> returned after reading Root directory MFT record. We should check the<br /> i_op is valid before trying to create the root dentry, otherwise we may<br /> encounter a NPD while mounting a image with a funny Root directory MFT<br /> record.<br /> <br /> [ 114.484325] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 114.484811] #PF: supervisor read access in kernel mode<br /> [ 114.485084] #PF: error_code(0x0000) - not-present page<br /> [ 114.485606] PGD 0 P4D 0<br /> [ 114.485975] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> [ 114.486570] CPU: 0 PID: 237 Comm: mount Tainted: G B 6.0.0-rc4 #28<br /> [ 114.486977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 114.488169] RIP: 0010:d_flags_for_inode+0xe0/0x110<br /> [ 114.488816] Code: 24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241<br /> [ 114.490326] RSP: 0018:ffff8880065e7aa8 EFLAGS: 00000296<br /> [ 114.490695] RAX: 0000000000000001 RBX: ffff888008ccd750 RCX: ffffffff84af2aea<br /> [ 114.490986] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff87abd020<br /> [ 114.491364] RBP: ffff8880065e7ac8 R08: 0000000000000001 R09: fffffbfff0f57a05<br /> [ 114.491675] R10: ffffffff87abd027 R11: fffffbfff0f57a04 R12: 0000000000000000<br /> [ 114.491954] R13: 0000000000000008 R14: 0000000000000000 R15: ffff888008ccd750<br /> [ 114.492397] FS: 00007fdc8a627e40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000<br /> [ 114.492797] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 114.493150] CR2: 0000000000000008 CR3: 00000000013ba000 CR4: 00000000000006f0<br /> [ 114.493671] Call Trace:<br /> [ 114.493890] <br /> [ 114.494075] __d_instantiate+0x24/0x1c0<br /> [ 114.494505] d_instantiate.part.0+0x35/0x50<br /> [ 114.494754] d_make_root+0x53/0x80<br /> [ 114.494998] ntfs_fill_super+0x1232/0x1b50<br /> [ 114.495260] ? put_ntfs+0x1d0/0x1d0<br /> [ 114.495499] ? vsprintf+0x20/0x20<br /> [ 114.495723] ? set_blocksize+0x95/0x150<br /> [ 114.495964] get_tree_bdev+0x232/0x370<br /> [ 114.496272] ? put_ntfs+0x1d0/0x1d0<br /> [ 114.496502] ntfs_fs_get_tree+0x15/0x20<br /> [ 114.496859] vfs_get_tree+0x4c/0x130<br /> [ 114.497099] path_mount+0x654/0xfe0<br /> [ 114.497507] ? putname+0x80/0xa0<br /> [ 114.497933] ? finish_automount+0x2e0/0x2e0<br /> [ 114.498362] ? putname+0x80/0xa0<br /> [ 114.498571] ? kmem_cache_free+0x1c4/0x440<br /> [ 114.498819] ? putname+0x80/0xa0<br /> [ 114.499069] do_mount+0xd6/0xf0<br /> [ 114.499343] ? path_mount+0xfe0/0xfe0<br /> [ 114.499683] ? __kasan_check_write+0x14/0x20<br /> [ 114.500133] __x64_sys_mount+0xca/0x110<br /> [ 114.500592] do_syscall_64+0x3b/0x90<br /> [ 114.500930] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 114.501294] RIP: 0033:0x7fdc898e948a<br /> [ 114.501542] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 114.502716] RSP: 002b:00007ffd793e58f8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> [ 114.503175] RAX: ffffffffffffffda RBX: 0000564b2228f060 RCX: 00007fdc898e948a<br /> [ 114.503588] RDX: 0000564b2228f260 RSI: 0000564b2228f2e0 RDI: 0000564b22297ce0<br /> [ 114.504925] RBP: 0000000000000000 R08: 0000564b2228f280 R09: 0000000000000020<br /> [ 114.505484] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564b22297ce0<br /> [ 114.505823] R13: 0000564b2228f260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 114.506562] <br /> [ 114.506887] Modules linked in:<br /> [ 114.507648] CR2: 0000000000000008<br /> [ 114.508884] ---[ end trace 0000000000000000 ]---<br /> [ 114.509675] RIP: 0010:d_flags_for_inode+0xe0/0x110<br /> [ 114.510140] Code: 24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241<br /> [ 114.511762] RSP: 0018:ffff8880065e7aa8 EFLAGS: 00000296<br /> [ 114.512401] RAX: 0000000000000001 RBX: ffff888008ccd750 RCX: ffffffff84af2aea<br /> [ 114.51<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026

CVE-2022-50740

Publication date:
24/12/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs()<br /> <br /> Syzkaller reports a long-known leak of urbs in<br /> ath9k_hif_usb_dealloc_tx_urbs().<br /> <br /> The cause of the leak is that usb_get_urb() is called but usb_free_urb()<br /> (or usb_put_urb()) is not called inside usb_kill_urb() as urb-&gt;dev or<br /> urb-&gt;ep fields have not been initialized and usb_kill_urb() returns<br /> immediately.<br /> <br /> The patch removes trying to kill urbs located in hif_dev-&gt;tx.tx_buf<br /> because hif_dev-&gt;tx.tx_buf is not supposed to contain urbs which are in<br /> pending state (the pending urbs are stored in hif_dev-&gt;tx.tx_pending).<br /> The tx.tx_lock is acquired so there should not be any changes in the list.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2026