Total
1928 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-48794 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: at86rf230: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. In the Tx case we then leak the skb structure. Free the skb structure upon error before returning when appropriate. As the 'is_tx = 0' cannot be moved in the complete handler because of a possible race between the delay in switching to STATE_RX_AACK_ON and a new interrupt, we introduce an intermediate 'was_tx' boolean just for this purpose. There is no Fixes tag applying here, many changes have been made on this area and the issue kind of always existed. | |||||
| CVE-2022-48776 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mtd: parsers: qcom: Fix missing free for pparts in cleanup Mtdpart doesn't free pparts when a cleanup function is declared. Add missing free for pparts in cleanup function for smem to fix the leak. | |||||
| CVE-2022-48775 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()： If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). | |||||
| CVE-2022-48768 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: tracing/histogram: Fix a potential memory leak for kstrdup() kfree() is missing on an error path to free the memory allocated by kstrdup(): p = param = kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). | |||||
| CVE-2022-48764 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.3 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2} Free the "struct kvm_cpuid_entry2" array on successful post-KVM_RUN KVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid() free the array only on failure. BUG: memory leak unreferenced object 0xffff88810963a800 (size 2048): comm "syz-executor025", pid 3610, jiffies 4294944928 (age 8.080s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00 ................ 47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00 GenuntelineI.... backtrace: [<ffffffff814948ee>] kmalloc_node include/linux/slab.h:604 [inline] [<ffffffff814948ee>] kvmalloc_node+0x3e/0x100 mm/util.c:580 [<ffffffff814950f2>] kvmalloc include/linux/slab.h:732 [inline] [<ffffffff814950f2>] vmemdup_user+0x22/0x100 mm/util.c:199 [<ffffffff8109f5ff>] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423 [<ffffffff810711b9>] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251 [<ffffffff8103e92d>] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066 [<ffffffff815afacc>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff815afacc>] __do_sys_ioctl fs/ioctl.c:874 [inline] [<ffffffff815afacc>] __se_sys_ioctl fs/ioctl.c:860 [inline] [<ffffffff815afacc>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 [<ffffffff844a3335>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff844a3335>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae | |||||
| CVE-2022-48763 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Forcibly leave nested virt when SMM state is toggled Forcibly leave nested virtualization operation if userspace toggles SMM state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace forces the vCPU out of SMM while it's post-VMXON and then injects an SMI, vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both vmxon=false and smm.vmxon=false, but all other nVMX state allocated. Don't attempt to gracefully handle the transition as (a) most transitions are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't sufficient information to handle all transitions, e.g. SVM wants access to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede KVM_SET_NESTED_STATE during state restore as the latter disallows putting the vCPU into L2 if SMM is active, and disallows tagging the vCPU as being post-VMXON in SMM if SMM is not active. Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU in an architecturally impossible state. WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline] WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Modules linked in: CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline] RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00 Call Trace: <TASK> kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123 kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline] kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460 kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline] kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline] kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250 kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273 __fput+0x286/0x9f0 fs/file_table.c:311 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x4b0/0x28c0 kernel/signal.c:2862 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> | |||||
| CVE-2022-48753 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in disk_register_independent_access_ranges kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by adding kobject_put(). Callback function blk_ia_ranges_sysfs_release() in kobject_put() can handle the pointer "iars" properly. | |||||
| CVE-2022-48724 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated"). For tear down scenario, fn is only freed after fail to allocate ir_domain, though it also should be freed in case dmar_enable_qi returns error. Besides free fn, irq_domain and ir_msi_domain need to be removed as well if intel_setup_irq_remapping fails to enable queued invalidation. Improve the rewinding path by add out_free_ir_domain and out_free_fwnode lables per Baolu's suggestion. | |||||
| CVE-2022-48722 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: ca8210: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. We then leak the skb structure. Free the skb structure upon error before returning. | |||||
| CVE-2022-48709 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ice: switch: fix potential memleak in ice_add_adv_recipe() When ice_add_special_words() fails, the 'rm' is not released, which will lead to a memory leak. Fix this up by going to 'err_unroll' label. Compile tested only. | |||||
| CVE-2022-48706 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Do proper cleanup if IFCVF init fails ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. | |||||
| CVE-2022-48699 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: sched/debug: fix dentry leak in update_sched_domain_debugfs Kuyo reports that the pattern of using debugfs_remove(debugfs_lookup()) leaks a dentry and with a hotplug stress test, the machine eventually runs out of memory. Fix this up by using the newly created debugfs_lookup_and_remove() call instead which properly handles the dentry reference counting logic. | |||||
| CVE-2022-48698 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.3 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix memory leak when using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). | |||||
| CVE-2022-48693 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs In brcmstb_pm_probe(), there are two kinds of leak bugs: (1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path | |||||
| CVE-2022-48691 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: clean up hook list when offload flags check fails splice back the hook list so nft_chain_release_hook() has a chance to release the hooks. BUG: memory leak unreferenced object 0xffff88810180b100 (size 96): comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s) hex dump (first 32 bytes): 28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#..... 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................ backtrace: [<ffffffff83a8c59b>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83a8c59b>] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901 [<ffffffff83a9239a>] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline] [<ffffffff83a9239a>] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073 [<ffffffff83a9b14b>] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218 [<ffffffff83a9c41b>] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593 [<ffffffff83a3d6a6>] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517 [<ffffffff83a3db79>] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline] [<ffffffff83a3db79>] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656 [<ffffffff83a13b17>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff83a13b17>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff83a13fd6>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff83865ab6>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff83865ab6>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8386601c>] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482 [<ffffffff8386a918>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff8386aaa8>] __sys_sendmsg+0x88/0x100 net/socket.c:2565 [<ffffffff845e5955>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e5955>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd | |||||
| CVE-2022-48690 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ice: Fix DMA mappings leak Fix leak, when user changes ring parameters. During reallocation of RX buffers, new DMA mappings are created for those buffers. New buffers with different RX ring count should substitute older ones, but those buffers were freed in ice_vsi_cfg_rxq and reallocated again with ice_alloc_rx_buf. kfree on rx_buf caused leak of already mapped DMA. Reallocate ZC with xdp_buf struct, when BPF program loads. Reallocate back to rx_buf, when BPF program unloads. If BPF program is loaded/unloaded and XSK pools are created, reallocate RX queues accordingly in XDP_SETUP_XSK_POOL handler. 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 | |||||
| CVE-2022-48669 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix potential memleak in papr_get_attr() `buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure. | |||||
| CVE-2022-48656 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get() We should call of_node_put() for the reference returned by of_parse_phandle() in fail path or when it is not used anymore. Here we only need to move the of_node_put() before the check. | |||||
| CVE-2022-48642 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error. | |||||
| CVE-2022-48641 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix memory leak when blob is malformed The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this. | |||||