Total
980 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-26734 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: devlink: fix possible use-after-free and memory leaks in devlink_init() The pernet operations structure for the subsystem must be registered before registering the generic netlink family. Make an unregister in case of unsuccessful registration. | ||||
| CVE-2021-47199 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT, Fix multiple allocations and memleak of mod acts CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it. Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached. Also the driver never releases the allocated mod hdr actions and causing a memleak. Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put(). backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core] | ||||
| CVE-2024-35975 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix transmit scheduler resource leak Inorder to support shaping and scheduling, Upon class creation Netdev driver allocates trasmit schedulers. The previous patch which added support for Round robin scheduling has a bug due to which driver is not freeing transmit schedulers post class deletion. This patch fixes the same. | ||||
| CVE-2024-36954 | 3 Debian, Linux, Redhat | 3 Debian Linux, Linux Kernel, Enterprise Linux | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tipc: fix a possible memleak in tipc_buf_append __skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path. | ||||
| CVE-2024-53210 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv] | ||||
| CVE-2024-56534 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: isofs: avoid memory leak in iocharset A memleak was found as below: unreferenced object 0xffff0000d10164d8 (size 8): comm "pool-udisksd", pid 108217, jiffies 4295408555 hex dump (first 8 bytes): 75 74 66 38 00 cc cc cc utf8.... backtrace (crc de430d31): [<ffff800081046e6c>] kmemleak_alloc+0xb8/0xc8 [<ffff8000803e6c3c>] __kmalloc_node_track_caller_noprof+0x380/0x474 [<ffff800080363b74>] kstrdup+0x70/0xfc [<ffff80007bb3c6a4>] isofs_parse_param+0x228/0x2c0 [isofs] [<ffff8000804d7f68>] vfs_parse_fs_param+0xf4/0x164 [<ffff8000804d8064>] vfs_parse_fs_string+0x8c/0xd4 [<ffff8000804d815c>] vfs_parse_monolithic_sep+0xb0/0xfc [<ffff8000804d81d8>] generic_parse_monolithic+0x30/0x3c [<ffff8000804d8bfc>] parse_monolithic_mount_data+0x40/0x4c [<ffff8000804b6a64>] path_mount+0x6c4/0x9ec [<ffff8000804b6e38>] do_mount+0xac/0xc4 [<ffff8000804b7494>] __arm64_sys_mount+0x16c/0x2b0 [<ffff80008002b8dc>] invoke_syscall+0x7c/0x104 [<ffff80008002ba44>] el0_svc_common.constprop.1+0xe0/0x104 [<ffff80008002ba94>] do_el0_svc+0x2c/0x38 [<ffff800081041108>] el0_svc+0x3c/0x1b8 The opt->iocharset is freed inside the isofs_fill_super function, But there may be situations where it's not possible to enter this function. For example, in the get_tree_bdev_flags function,when encountering the situation where "Can't mount, would change RO state," In such a case, isofs_fill_super will not have the opportunity to be called,which means that opt->iocharset will not have the chance to be freed,ultimately leading to a memory leak. Let's move the memory freeing of opt->iocharset into isofs_free_fc function. | ||||
| CVE-2024-56542 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a memleak issue when driver is removed Running "modprobe amdgpu" the second time (followed by a modprobe -r amdgpu) causes a call trace like: [ 845.212163] Memory manager not clean during takedown. [ 845.212170] WARNING: CPU: 4 PID: 2481 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x2b/0x40 [ 845.212177] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amddrm_buddy(OE) amdxcp(OE) amd_sched(OE) drm_exec drm_suballoc_helper drm_display_helper i2c_algo_bit amdttm(OE) amdkcl(OE) cec rc_core sunrpc qrtr intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi edac_mce_amd snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_usb_audio snd_hda_codec snd_usbmidi_lib kvm_amd snd_hda_core snd_ump mc snd_hwdep kvm snd_pcm snd_seq_midi snd_seq_midi_event irqbypass crct10dif_pclmul snd_rawmidi polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 snd_seq aesni_intel crypto_simd snd_seq_device cryptd snd_timer mfd_aaeon asus_nb_wmi eeepc_wmi joydev asus_wmi snd ledtrig_audio sparse_keymap ccp wmi_bmof input_leds k10temp i2c_piix4 platform_profile rapl soundcore gpio_amdpt mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid ahci xhci_pci igc crc32_pclmul libahci xhci_pci_renesas video [ 845.212284] wmi [last unloaded: amddrm_ttm_helper(OE)] [ 845.212290] CPU: 4 PID: 2481 Comm: modprobe Tainted: G W OE 6.8.0-31-generic #31-Ubuntu [ 845.212296] RIP: 0010:drm_mm_takedown+0x2b/0x40 [ 845.212300] Code: 1f 44 00 00 48 8b 47 38 48 83 c7 38 48 39 f8 75 09 31 c0 31 ff e9 90 2e 86 00 55 48 c7 c7 d0 f6 8e 8a 48 89 e5 e8 f5 db 45 ff <0f> 0b 5d 31 c0 31 ff e9 74 2e 86 00 66 0f 1f 84 00 00 00 00 00 90 [ 845.212302] RSP: 0018:ffffb11302127ae0 EFLAGS: 00010246 [ 845.212305] RAX: 0000000000000000 RBX: ffff92aa5020fc08 RCX: 0000000000000000 [ 845.212307] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 845.212309] RBP: ffffb11302127ae0 R08: 0000000000000000 R09: 0000000000000000 [ 845.212310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004 [ 845.212312] R13: ffff92aa50200000 R14: ffff92aa5020fb10 R15: ffff92aa5020faa0 [ 845.212313] FS: 0000707dd7c7c080(0000) GS:ffff92b93de00000(0000) knlGS:0000000000000000 [ 845.212316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 845.212318] CR2: 00007d48b0aee200 CR3: 0000000115a58000 CR4: 0000000000f50ef0 [ 845.212320] PKRU: 55555554 [ 845.212321] Call Trace: [ 845.212323] <TASK> [ 845.212328] ? show_regs+0x6d/0x80 [ 845.212333] ? __warn+0x89/0x160 [ 845.212339] ? drm_mm_takedown+0x2b/0x40 [ 845.212344] ? report_bug+0x17e/0x1b0 [ 845.212350] ? handle_bug+0x51/0xa0 [ 845.212355] ? exc_invalid_op+0x18/0x80 [ 845.212359] ? asm_exc_invalid_op+0x1b/0x20 [ 845.212366] ? drm_mm_takedown+0x2b/0x40 [ 845.212371] amdgpu_gtt_mgr_fini+0xa9/0x130 [amdgpu] [ 845.212645] amdgpu_ttm_fini+0x264/0x340 [amdgpu] [ 845.212770] amdgpu_bo_fini+0x2e/0xc0 [amdgpu] [ 845.212894] gmc_v12_0_sw_fini+0x2a/0x40 [amdgpu] [ 845.213036] amdgpu_device_fini_sw+0x11a/0x590 [amdgpu] [ 845.213159] amdgpu_driver_release_kms+0x16/0x40 [amdgpu] [ 845.213302] devm_drm_dev_init_release+0x5e/0x90 [ 845.213305] devm_action_release+0x12/0x30 [ 845.213308] release_nodes+0x42/0xd0 [ 845.213311] devres_release_all+0x97/0xe0 [ 845.213314] device_unbind_cleanup+0x12/0x80 [ 845.213317] device_release_driver_internal+0x230/0x270 [ 845.213319] ? srso_alias_return_thunk+0x5/0xfbef5 This is caused by lost memory during early init phase. First time driver is removed, memory is freed but when second time the driver is inserted, VBIOS dmub is not active, since the PSP policy is to retain the driver loaded version on subsequent warm boots. Hence, communication with VBIOS DMUB fails. Fix this by aborting further comm ---truncated--- | ||||
| CVE-2024-56572 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal() The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here. To mitigate this, free the buffer when allegro_alloc_buffer fails. | ||||
| CVE-2024-56632 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix the memleak while create new ctrl failed Now while we create new ctrl failed, we have not free the tagset occupied by admin_q, here try to fix it. | ||||
| CVE-2021-47093 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel_pmc_core: fix memleak on registration failure In case device registration fails during module initialisation, the platform device structure needs to be freed using platform_device_put() to properly free all resources (e.g. the device name). | ||||
| CVE-2021-47455 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ptp: Fix possible memory leak in ptp_clock_register() I got memory leak as follows when doing fault injection test: unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33] When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release(). | ||||
| CVE-2024-7095 | 2025-01-14 | 4.3 Medium | ||
| On affected platforms running Arista EOS with SNMP configured, if “snmp-server transmit max-size” is configured, under some circumstances a specially crafted packet can cause the snmpd process to leak memory. This may result in the snmpd process being terminated (causing SNMP requests to time out until snmpd is restarted) and memory pressure for other processes on the switch. Increased memory pressure can cause processes other than snmpd to be at risk for unexpected termination as well. | ||||
| CVE-2023-52643 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iio: core: fix memleak in iio_device_register_sysfs When iio_device_register_sysfs_group() fails, we should free iio_dev_opaque->chan_attr_group.attrs to prevent potential memleak. | ||||
| CVE-2024-26829 | 1 Linux | 1 Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: fix a memleak in irtoy_tx When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak. | ||||
| CVE-2024-26839 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered. | ||||
| CVE-2024-27388 | 3 Debian, Linux, Redhat | 3 Debian Linux, Linux Kernel, Enterprise Linux | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths. | ||||
| CVE-2023-52662 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init. | ||||
| CVE-2024-35828 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). | ||||
| CVE-2024-1394 | 1 Redhat | 23 Ansible Automation Platform, Ansible Automation Platform Developer, Ansible Automation Platform Inside and 20 more | 2025-01-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-5156 | 2 Gnu, Redhat | 2 Glibc, Enterprise Linux | 2025-01-10 | 7.5 High |
| A flaw was found in the GNU C Library. A recent fix for CVE-2023-4806 introduced the potential for a memory leak, which may result in an application crash. | ||||