Total
1435 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-38057 | 1 Linux | 1 Linux Kernel | 2025-11-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb. | ||||
| CVE-2025-37955 | 1 Linux | 1 Linux Kernel | 2025-11-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable() The selftests added to our CI by Bui Quang Minh recently reveals that there is a mem leak on the error path of virtnet_xsk_pool_enable(): unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ||||
| CVE-2025-37980 | 1 Linux | 1 Linux Kernel | 2025-11-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: block: fix resource leak in blk_register_queue() error path When registering a queue fails after blk_mq_sysfs_register() is successful but the function later encounters an error, we need to clean up the blk_mq_sysfs resources. Add the missing blk_mq_sysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak. | ||||
| CVE-2022-49971 | 1 Linux | 1 Linux Kernel | 2025-11-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix a potential gpu_metrics_table memory leak Memory is allocated for gpu_metrics_table in smu_v13_0_4_init_smc_tables(), but not freed in smu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it. | ||||
| CVE-2022-50027 | 1 Linux | 1 Linux Kernel | 2025-11-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe. If ret_val is non-zero, then free the iocbq request structure. | ||||
| CVE-2022-50025 | 1 Linux | 1 Linux Kernel | 2025-11-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cxl: Fix a memory leak in an error handling path A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the error handling path of afu_allocate_irqs(). | ||||
| CVE-2022-50042 | 1 Linux | 1 Linux Kernel | 2025-11-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: genl: fix error path memory leak in policy dumping If construction of the array of policies fails when recording non-first policy we need to unwind. netlink_policy_dump_add_policy() itself also needs fixing as it currently gives up on error without recording the allocated pointer in the pstate pointer. | ||||
| CVE-2022-50046 | 1 Linux | 1 Linux Kernel | 2025-11-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change() The issue happens on some error handling paths. When the function fails to grab the object `xprt`, it simply returns 0, forgetting to decrease the reference count of another object `xps`, which is increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount leaks. Also, the function forgets to check whether `xps` is valid before using it, which may result in NULL-dereferencing issues. Fix it by adding proper error handling code when either `xprt` or `xps` is NULL. | ||||
| CVE-2022-50060 | 1 Linux | 1 Linux Kernel | 2025-11-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix mcam entry resource leak The teardown sequence in FLR handler returns if no NIX LF is attached to PF/VF because it indicates that graceful shutdown of resources already happened. But there is a chance of all allocated MCAM entries not being freed by PF/VF. Hence free mcam entries even in case of detached LF. | ||||
| CVE-2024-1394 | 1 Redhat | 23 Ansible Automation Platform, Ansible Automation Platform Developer, Ansible Automation Platform Inside and 20 more | 2025-11-13 | 7.5 High |
| A memory leak flaw was found in Golang in the RSA encrypting/decrypting code, which might lead to a resource exhaustion vulnerability using attacker-controlled inputs. The memory leak happens in github.com/golang-fips/openssl/openssl/rsa.go#L113. The objects leaked are pkey and ctx. That function uses named return parameters to free pkey and ctx if there is an error initializing the context or setting the different properties. All return statements related to error cases follow the "return nil, nil, fail(...)" pattern, meaning that pkey and ctx will be nil inside the deferred function that should free them. | ||||
| CVE-2023-53092 | 1 Linux | 1 Linux Kernel | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: interconnect: exynos: fix node leak in probe PM QoS error path Make sure to add the newly allocated interconnect node to the provider before adding the PM QoS request so that the node is freed on errors. | ||||
| CVE-2023-53096 | 1 Linux | 1 Linux Kernel | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed. | ||||
| CVE-2023-53097 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | ||||
| CVE-2023-53068 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. Additionally prevent integer underflow when size is less than ETH_FCS_LEN. | ||||
| CVE-2023-53069 | 1 Linux | 1 Linux Kernel | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-vf: Add missing free for alloc_percpu Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid memory leak, same as the "pf->hw.lmt_info" in `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`. | ||||
| CVE-2023-53078 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not freed, which will cause following memleak: unreferenced object 0xffff88810b2c6980 (size 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30 Fix the problem by freeing 'qdata' in error path. | ||||
| CVE-2025-37874 | 1 Linux | 1 Linux Kernel | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix memory leak in ngbe_probe() error path When ngbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent error paths after ngbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when ngbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init(). | ||||
| CVE-2025-37872 | 1 Linux | 1 Linux Kernel | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix memory leak in txgbe_probe() error path When txgbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent error paths after txgbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when txgbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init(). | ||||
| CVE-2023-53050 | 1 Linux | 1 Linux Kernel | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix memory leak in margining Memory for the usb4->margining needs to be relased for the upstream port of the router as well, even though the debugfs directory gets released with the router device removal. Fix this. | ||||
| CVE-2023-53054 | 1 Linux | 1 Linux Kernel | 2025-11-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix a devres leak in hw_enable upon suspend resume Each time the platform goes to low power, PM suspend / resume routines call: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset(). This adds a new devres each time. This may also happen at runtime, as dwc2_lowlevel_hw_enable() can be called from udc_start(). This can be seen with tracing: - echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable - go to low power - cat /sys/kernel/debug/tracing/trace A new "ADD" entry is found upon each low power cycle: ... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes) ... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes) ... A second issue is addressed here: - regulator_bulk_enable() is called upon each PM cycle (suspend/resume). - regulator_bulk_disable() never gets called. So the reference count for these regulators constantly increase, by one upon each low power cycle, due to missing regulator_bulk_disable() call in __dwc2_lowlevel_hw_disable(). The original fix that introduced the devm_add_action_or_reset() call, fixed an issue during probe, that happens due to other errors in dwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without disabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL. Rather fix the error path: disable all the low level hardware in the error path, by using the "hsotg->ll_hw_enabled" flag. Checking dr_mode has been introduced to avoid a dual call to dwc2_lowlevel_hw_disable(). "ll_hw_enabled" should achieve the same (and is used currently in the remove() routine). | ||||