Export limit exceeded: 26160 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Export limit exceeded: 424863 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Export limit exceeded: 26253 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Use the Query Builder to create your own search query, or check out the documentation to learn the search syntax.

Search Examples

CVEs in KEV CVEs with EPSS >= 80% Crit. Microsoft High Apache SQL Injection (CWE-89) Linux Kernel High (CVSS 3.1) Apache Struts RCE (Remote Code Execution) XSS (CWE-79) Critical (CVSS 4.0) CVEs to check

Search Results (26253 CVEs found)

Export CSV
CVE Vendors Products Updated CVSS v3.1
CVE-2022-50662 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: fix memory leak in hns_roce_alloc_mr() When hns_roce_mr_enable() failed in hns_roce_alloc_mr(), mr_key is not released. Compiled test only.
CVE-2022-50667 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix memory leak in vmw_mksstat_add_ioctl() If the copy of the description string from userspace fails, then the page for the instance descriptor doesn't get freed before returning -EFAULT, which leads to a memleak.
CVE-2022-50674 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: riscv: vdso: fix NULL deference in vdso_join_timens() when vfork Testing tools/testing/selftests/timens/vfork_exec.c got below kernel log: [ 6.838454] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000020 [ 6.842255] Oops [#1] [ 6.842871] Modules linked in: [ 6.844249] CPU: 1 PID: 64 Comm: vfork_exec Not tainted 6.0.0-rc3-rt15+ #8 [ 6.845861] Hardware name: riscv-virtio,qemu (DT) [ 6.848009] epc : vdso_join_timens+0xd2/0x110 [ 6.850097] ra : vdso_join_timens+0xd2/0x110 [ 6.851164] epc : ffffffff8000635c ra : ffffffff8000635c sp : ff6000000181fbf0 [ 6.852562] gp : ffffffff80cff648 tp : ff60000000fdb700 t0 : 3030303030303030 [ 6.853852] t1 : 0000000000000030 t2 : 3030303030303030 s0 : ff6000000181fc40 [ 6.854984] s1 : ff60000001e6c000 a0 : 0000000000000010 a1 : ffffffff8005654c [ 6.856221] a2 : 00000000ffffefff a3 : 0000000000000000 a4 : 0000000000000000 [ 6.858114] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038 [ 6.859484] s2 : ff60000001e6c068 s3 : ff6000000108abb0 s4 : 0000000000000000 [ 6.860751] s5 : 0000000000001000 s6 : ffffffff8089dc40 s7 : ffffffff8089dc38 [ 6.862029] s8 : ffffffff8089dc30 s9 : ff60000000fdbe38 s10: 000000000000005e [ 6.863304] s11: ffffffff80cc3510 t3 : ffffffff80d1112f t4 : ffffffff80d1112f [ 6.864565] t5 : ffffffff80d11130 t6 : ff6000000181fa00 [ 6.865561] status: 0000000000000120 badaddr: 0000000000000020 cause: 000000000000000d [ 6.868046] [<ffffffff8008dc94>] timens_commit+0x38/0x11a [ 6.869089] [<ffffffff8008dde8>] timens_on_fork+0x72/0xb4 [ 6.870055] [<ffffffff80190096>] begin_new_exec+0x3c6/0x9f0 [ 6.871231] [<ffffffff801d826c>] load_elf_binary+0x628/0x1214 [ 6.872304] [<ffffffff8018ee7a>] bprm_execve+0x1f2/0x4e4 [ 6.873243] [<ffffffff8018f90c>] do_execveat_common+0x16e/0x1ee [ 6.874258] [<ffffffff8018f9c8>] sys_execve+0x3c/0x48 [ 6.875162] [<ffffffff80003556>] ret_from_syscall+0x0/0x2 [ 6.877484] ---[ end trace 0000000000000000 ]--- This is because the mm->context.vdso_info is NULL in vfork case. From another side, mm->context.vdso_info either points to vdso info for RV64 or vdso info for compat, there's no need to bloat riscv's mm_context_t, we can handle the difference when setup the additional page for vdso.
CVE-2022-50679 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix DMA mappings leak During reallocation of RX buffers, new DMA mappings are created for those buffers. steps for reproduction: while : do for ((i=0; i<=8160; i=i+32)) do ethtool -G enp130s0f0 rx $i tx $i sleep 0.5 ethtool -g enp130s0f0 done done This resulted in crash: i40e 0000:01:00.1: Unable to allocate memory for the Rx descriptor ring, size=65536 Driver BUG WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:141 xdp_rxq_info_unreg+0x43/0x50 Call Trace: i40e_free_rx_resources+0x70/0x80 [i40e] i40e_set_ringparam+0x27c/0x800 [i40e] ethnl_set_rings+0x1b2/0x290 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? rings_fill_reply+0x1a0/0x1a0 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? handle_mm_fault+0xbe/0x1e0 ? syscall_trace_enter+0x1d3/0x2c0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f5eac8b035b Missing register, driver bug WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:119 xdp_rxq_info_unreg_mem_model+0x69/0x140 Call Trace: xdp_rxq_info_unreg+0x1e/0x50 i40e_free_rx_resources+0x70/0x80 [i40e] i40e_set_ringparam+0x27c/0x800 [i40e] ethnl_set_rings+0x1b2/0x290 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? rings_fill_reply+0x1a0/0x1a0 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? handle_mm_fault+0xbe/0x1e0 ? syscall_trace_enter+0x1d3/0x2c0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f5eac8b035b This was caused because of new buffers with different RX ring count should substitute older ones, but those buffers were freed in i40e_configure_rx_ring and reallocated again with i40e_alloc_rx_bi, thus kfree on rx_bi caused leak of already mapped DMA. Fix this by reallocating ZC with rx_bi_zc struct when BPF program loads. Additionally reallocate back to rx_bi when BPF program unloads. If BPF program is loaded/unloaded and XSK pools are created, reallocate RX queues accordingly in XSP_SETUP_XSK_POOL handler.
CVE-2022-50705 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: defer fsnotify calls to task context We can't call these off the kiocb completion as that might be off soft/hard irq context. Defer the calls to when we process the task_work for this request. That avoids valid complaints like: stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g105a36f3694e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_usage_bug kernel/locking/lockdep.c:3961 [inline] valid_state kernel/locking/lockdep.c:3973 [inline] mark_lock_irq kernel/locking/lockdep.c:4176 [inline] mark_lock.part.0.cold+0x18/0xd8 kernel/locking/lockdep.c:4632 mark_lock kernel/locking/lockdep.c:4596 [inline] mark_usage kernel/locking/lockdep.c:4527 [inline] __lock_acquire+0x11d9/0x56d0 kernel/locking/lockdep.c:5007 lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 __fs_reclaim_acquire mm/page_alloc.c:4674 [inline] fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688 might_alloc include/linux/sched/mm.h:271 [inline] slab_pre_alloc_hook mm/slab.h:700 [inline] slab_alloc mm/slab.c:3278 [inline] __kmem_cache_alloc_lru mm/slab.c:3471 [inline] kmem_cache_alloc+0x39/0x520 mm/slab.c:3491 fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline] fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline] fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948 send_to_group fs/notify/fsnotify.c:360 [inline] fsnotify+0xafb/0x1680 fs/notify/fsnotify.c:570 __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230 fsnotify_parent include/linux/fsnotify.h:77 [inline] fsnotify_file include/linux/fsnotify.h:99 [inline] fsnotify_access include/linux/fsnotify.h:309 [inline] __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195 io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228 iomap_dio_complete_work fs/iomap/direct-io.c:144 [inline] iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap/direct-io.c:178 bio_endio+0x5f9/0x780 block/bio.c:1564 req_bio_endio block/blk-mq.c:695 [inline] blk_update_request+0x3fc/0x1300 block/blk-mq.c:825 scsi_end_request+0x7a/0x9a0 drivers/scsi/scsi_lib.c:541 scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971 scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438 blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1022 __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 common_interrupt+0xa9/0xc0 arch/x86/kernel/irq.c:240
CVE-2022-50706 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: net/ieee802154: don't warn zero-sized raw_sendmsg() syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1], for PF_IEEE802154 socket's zero-sized raw_sendmsg() request is hitting __dev_queue_xmit() with skb->len == 0. Since PF_IEEE802154 socket's zero-sized raw_sendmsg() request was able to return 0, don't call __dev_queue_xmit() if packet length is 0. ---------- #include <sys/socket.h> #include <netinet/in.h> int main(int argc, char *argv[]) { struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) }; struct iovec iov = { }; struct msghdr hdr = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 }; sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0); return 0; } ---------- Note that this might be a sign that commit fd1894224407c484 ("bpf: Don't redirect packets with invalid pkt_len") should be reverted, for skb->len == 0 was acceptable for at least PF_IEEE802154 socket.
CVE-2022-50712 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: devlink: hold region lock when flushing snapshots Netdevsim triggers a splat on reload, when it destroys regions with snapshots pending: WARNING: CPU: 1 PID: 787 at net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140 CPU: 1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c #580 RIP: 0010:devlink_region_snapshot_del+0x12e/0x140 Call Trace: <TASK> devl_region_destroy+0x70/0x140 nsim_dev_reload_down+0x2f/0x60 [netdevsim] devlink_reload+0x1f7/0x360 devlink_nl_cmd_reload+0x6ce/0x860 genl_family_rcv_msg_doit.isra.0+0x145/0x1c0 This is the locking assert in devlink_region_snapshot_del(), we're supposed to be holding the region->snapshot_lock here.
CVE-2022-50714 1 Linux 1 Linux Kernel 2026-04-15 7.0 High
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921e: fix rmmod crash in driver reload test In insmod/rmmod stress test, the following crash dump shows up immediately. The problem is caused by missing mt76_dev in mt7921_pci_remove(). We should make sure the drvdata is ready before probe() finished. [168.862789] ================================================================== [168.862797] BUG: KASAN: user-memory-access in try_to_grab_pending+0x59/0x480 [168.862805] Write of size 8 at addr 0000000000006df0 by task rmmod/5361 [168.862812] CPU: 7 PID: 5361 Comm: rmmod Tainted: G OE 5.19.0-rc6 #1 [168.862816] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, 05/04/2020 [168.862820] Call Trace: [168.862822] <TASK> [168.862825] dump_stack_lvl+0x49/0x63 [168.862832] print_report.cold+0x493/0x6b7 [168.862845] kasan_report+0xa7/0x120 [168.862857] kasan_check_range+0x163/0x200 [168.862861] __kasan_check_write+0x14/0x20 [168.862866] try_to_grab_pending+0x59/0x480 [168.862870] __cancel_work_timer+0xbb/0x340 [168.862898] cancel_work_sync+0x10/0x20 [168.862902] mt7921_pci_remove+0x61/0x1c0 [mt7921e] [168.862909] pci_device_remove+0xa3/0x1d0 [168.862914] device_remove+0xc4/0x170 [168.862920] device_release_driver_internal+0x163/0x300 [168.862925] driver_detach+0xc7/0x1a0 [168.862930] bus_remove_driver+0xeb/0x2d0 [168.862935] driver_unregister+0x71/0xb0 [168.862939] pci_unregister_driver+0x30/0x230 [168.862944] mt7921_pci_driver_exit+0x10/0x1b [mt7921e] [168.862949] __x64_sys_delete_module+0x2f9/0x4b0 [168.862968] do_syscall_64+0x38/0x90 [168.862973] entry_SYSCALL_64_after_hwframe+0x63/0xcd Test steps: 1. insmode 2. do not ifup 3. rmmod quickly (within 1 second)
CVE-2022-50720 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: x86/apic: Don't disable x2APIC if locked The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC (or x2APIC). X2APIC mode is mostly compatible with legacy APIC, but it disables the memory-mapped APIC interface in favor of one that uses MSRs. The APIC mode is controlled by the EXT bit in the APIC MSR. The MMIO/xAPIC interface has some problems, most notably the APIC LEAK [1]. This bug allows an attacker to use the APIC MMIO interface to extract data from the SGX enclave. Introduce support for a new feature that will allow the BIOS to lock the APIC in x2APIC mode. If the APIC is locked in x2APIC mode and the kernel tries to disable the APIC or revert to legacy APIC mode a GP fault will occur. Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle the new locked mode when the LEGACY_XAPIC_DISABLED bit is set by preventing the kernel from trying to disable the x2APIC. On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX are enabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. If legacy APIC is required, then it SGX and TDX need to be disabled in the BIOS. [1]: https://aepicleak.com/aepicleak.pdf
CVE-2022-50721 1 Linux 1 Linux Kernel 2026-04-15 7.0 High
In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom-adm: fix wrong calling convention for prep_slave_sg The calling convention for pre_slave_sg is to return NULL on error and provide an error log to the system. Qcom-adm instead provide error pointer when an error occur. This indirectly cause kernel panic for example for the nandc driver that checks only if the pointer returned by device_prep_slave_sg is not NULL. Returning an error pointer makes nandc think the device_prep_slave_sg function correctly completed and makes the kernel panics later in the code. While nandc is the one that makes the kernel crash, it was pointed out that the real problem is qcom-adm not following calling convention for that function. To fix this, drop returning error pointer and return NULL with an error log.
CVE-2022-50723 1 Linux 1 Linux Kernel 2026-04-15 7.0 High
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix memory leak in bnxt_nvm_test() Free the kzalloc'ed buffer before returning in the success path.
CVE-2022-50725 1 Linux 1 Linux Kernel 2026-04-15 N/A
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init() KASAN reports a use-after-free: BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core] Call Trace: ... dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core] vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge] platform_probe+0xb6/0x170 ... Allocated by task 1238: ... dvb_register_device+0x1a7/0xa70 [dvb_core] dvb_dmxdev_init+0x2af/0x4a0 [dvb_core] vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge] ... Freed by task 1238: dvb_register_device+0x6d2/0xa70 [dvb_core] dvb_dmxdev_init+0x2af/0x4a0 [dvb_core] vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge] ... It is because the error handling in vidtv_bridge_dvb_init() is wrong. First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but goto fail_dmx(_dev): calls release functions again, which causes use-after-free. Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause out-of-bound when i finished its loop (i == NUM_FE). And the loop releasing is wrong, although now NUM_FE is 1 so it won't cause problem. Fix this by correctly releasing everything.
CVE-2022-50729 1 Linux 1 Linux Kernel 2026-04-15 N/A
In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix resource leak in ksmbd_session_rpc_open() When ksmbd_rpc_open() fails then it must call ksmbd_rpc_id_free() to undo the result of ksmbd_ipc_id_alloc().
CVE-2022-50731 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: crypto: akcipher - default implementation for setting a private key Changes from v1: * removed the default implementation from set_pub_key: it is assumed that an implementation must always have this callback defined as there are no use case for an algorithm, which doesn't need a public key Many akcipher implementations (like ECDSA) support only signature verifications, so they don't have all callbacks defined. Commit 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks") introduced default callbacks for sign/verify operations, which just return an error code. However, these are not enough, because before calling sign the caller would likely call set_priv_key first on the instantiated transform (as the in-kernel testmgr does). This function does not have a default stub, so the kernel crashes, when trying to set a private key on an akcipher, which doesn't support signature generation. I've noticed this, when trying to add a KAT vector for ECDSA signature to the testmgr. With this patch the testmgr returns an error in dmesg (as it should) instead of crashing the kernel NULL ptr dereference.
CVE-2022-50735 1 Linux 1 Linux Kernel 2026-04-15 7.0 High
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: do not run mt76u_status_worker if the device is not running Fix the following NULL pointer dereference avoiding to run mt76u_status_worker thread if the device is not running yet. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: mt76 mt76u_tx_status_data RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: mt76x02_send_tx_status+0x1d2/0xeb0 mt76x02_tx_status_data+0x8e/0xd0 mt76u_tx_status_data+0xe1/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480 ret_from_fork+0x1f/0x30 Modules linked in: --[ end trace 8df5d20fc5040f65 ]-- RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Moreover move stat_work schedule out of the for loop.
CVE-2022-50742 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: misc: ocxl: fix possible refcount leak in afu_ioctl() eventfd_ctx_put need to be called to put the refcount that gotten by eventfd_ctx_fdget when ocxl_irq_set_handler fails.
CVE-2022-50743 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: erofs: Fix pcluster memleak when its block address is zero syzkaller reported a memleak: https://syzkaller.appspot.com/bug?id=62f37ff612f0021641eda5b17f056f1668aa9aed unreferenced object 0xffff88811009c7f8 (size 136): ... backtrace: [<ffffffff821db19b>] z_erofs_do_read_page+0x99b/0x1740 [<ffffffff821dee9e>] z_erofs_readahead+0x24e/0x580 [<ffffffff814bc0d6>] read_pages+0x86/0x3d0 ... syzkaller constructed a case: in z_erofs_register_pcluster(), ztailpacking = false and map->m_pa = zero. This makes pcl->obj.index be zero although pcl is not a inline pcluster. Then following path adds refcount for grp, but the refcount won't be put because pcl is inline. z_erofs_readahead() z_erofs_do_read_page() # for another page z_erofs_collector_begin() erofs_find_workgroup() erofs_workgroup_get() Since it's illegal for the block address of a non-inlined pcluster to be zero, add check here to avoid registering the pcluster which would be leaked.
CVE-2022-50754 1 Linux 1 Linux Kernel 2026-04-15 N/A
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix a memleak in multi_transaction_new() In multi_transaction_new(), the variable t is not freed or passed out on the failure of copy_from_user(t->data, buf, size), which could lead to a memleak. Fix this bug by adding a put_multi_transaction(t) in the error path.
CVE-2022-50751 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: configfs: fix possible memory leak in configfs_create_dir() kmemleak reported memory leaks in configfs_create_dir(): unreferenced object 0xffff888009f6af00 (size 192): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... unreferenced object 0xffff888003ba7180 (size 96): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... This is because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing as: configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ... *dentry_unlink_inode()* configfs_d_iput() # s_count = 0, release However, if we failed in configfs_create(): configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode); There is no inode in the error path, so the configfs_d_iput() is lost and makes sd and fragment memory leaked. To fix this, when we failed in configfs_create(), manually call configfs_put(sd) to keep the refcount correct.
CVE-2022-50766 1 Linux 1 Linux Kernel 2026-04-15 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffer syzbot is reporting uninit-value in btrfs_clean_tree_block() [1], for commit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code") missed that btrfs_set_header_generation() in btrfs_init_new_buffer() must not be moved to after clean_tree_block() because clean_tree_block() is calling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs: Fix extent_buffer usage when nodesize != leafsize"). Since memzero_extent_buffer() will reset "struct btrfs_header" part, we can't move btrfs_set_header_generation() to before memzero_extent_buffer(). Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().