CWE-401
AllowedMissing Release of Memory after Effective Lifetime
Abstraction: Variant · Status: Draft
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
2124 vulnerabilities reference this CWE, most recent first.
GHSA-PMJ7-4375-32J4
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31In the Linux kernel, the following vulnerability has been resolved:
blk-mq: Fix kmemleak in blk_mq_init_allocated_queue
There is a kmemleak caused by modprobe null_blk.ko
unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
That is because q->ma_ops is set to NULL before blk_release_queue is called.
blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break;
xa_for_each_start(&q->hctx_table, j, hctx, j)
blk_mq_exit_hctx(q, set, hctx, j); [2]
if (!q->nr_hw_queues) [3]
goto err_hctxs;
err_exit: q->mq_ops = NULL; [4]
blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q);
[1]: blk_mq_alloc_and_init_hctx failed at i != 0. [2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and will be cleaned up in blk_mq_release. [3]: q->nr_hw_queues is 0. [4]: Set q->mq_ops to NULL. [5]: queue_is_mq returns false due to [4]. And blk_mq_release will not be called. The hctxs in q->unused_hctx_list are leaked.
To fix it, call blk_release_queue in exception path.
{
"affected": [],
"aliases": [
"CVE-2022-49901"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: Fix kmemleak in blk_mq_init_allocated_queue\n\nThere is a kmemleak caused by modprobe null_blk.ko\n\nunreferenced object 0xffff8881acb1f000 (size 1024):\n comm \"modprobe\", pid 836, jiffies 4294971190 (age 27.068s)\n hex dump (first 32 bytes):\n 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........\n ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S......\n backtrace:\n [\u003c000000004a10c249\u003e] kmalloc_node_trace+0x22/0x60\n [\u003c00000000648f7950\u003e] blk_mq_alloc_and_init_hctx+0x289/0x350\n [\u003c00000000af06de0e\u003e] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0\n [\u003c00000000e00c1872\u003e] blk_mq_init_allocated_queue+0x48c/0x1440\n [\u003c00000000d16b4e68\u003e] __blk_mq_alloc_disk+0xc8/0x1c0\n [\u003c00000000d10c98c3\u003e] 0xffffffffc450d69d\n [\u003c00000000b9299f48\u003e] 0xffffffffc4538392\n [\u003c0000000061c39ed6\u003e] do_one_initcall+0xd0/0x4f0\n [\u003c00000000b389383b\u003e] do_init_module+0x1a4/0x680\n [\u003c0000000087cf3542\u003e] load_module+0x6249/0x7110\n [\u003c00000000beba61b8\u003e] __do_sys_finit_module+0x140/0x200\n [\u003c00000000fdcfff51\u003e] do_syscall_64+0x35/0x80\n [\u003c000000003c0f1f71\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThat is because q-\u003ema_ops is set to NULL before blk_release_queue is\ncalled.\n\nblk_mq_init_queue_data\n blk_mq_init_allocated_queue\n blk_mq_realloc_hw_ctxs\n for (i = 0; i \u003c set-\u003enr_hw_queues; i++) {\n old_hctx = xa_load(\u0026q-\u003ehctx_table, i);\n if (!blk_mq_alloc_and_init_hctx(.., i, ..))\t\t[1]\n if (!old_hctx)\n\t break;\n\n xa_for_each_start(\u0026q-\u003ehctx_table, j, hctx, j)\n blk_mq_exit_hctx(q, set, hctx, j); \t\t\t[2]\n\n if (!q-\u003enr_hw_queues)\t\t\t\t\t[3]\n goto err_hctxs;\n\n err_exit:\n q-\u003emq_ops = NULL;\t\t\t \t\t\t[4]\n\n blk_put_queue\n blk_release_queue\n if (queue_is_mq(q))\t\t\t\t\t[5]\n blk_mq_release(q);\n\n[1]: blk_mq_alloc_and_init_hctx failed at i != 0.\n[2]: The hctxs allocated by [1] are moved to q-\u003eunused_hctx_list and\nwill be cleaned up in blk_mq_release.\n[3]: q-\u003enr_hw_queues is 0.\n[4]: Set q-\u003emq_ops to NULL.\n[5]: queue_is_mq returns false due to [4]. And blk_mq_release\nwill not be called. The hctxs in q-\u003eunused_hctx_list are leaked.\n\nTo fix it, call blk_release_queue in exception path.",
"id": "GHSA-pmj7-4375-32j4",
"modified": "2025-05-07T15:31:26Z",
"published": "2025-05-01T15:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49901"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2dc97e15a54b7bdf457848aa8c663c98a24e58a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/943f45b9399ed8b2b5190cbc797995edaa97f58f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PMW2-6GH9-J59G
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 15:33In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix memory leaks in weighted_interleave_auto_store()
weighted_interleave_auto_store() fetches old_wi_state inside the if (!input) block only. This causes two memory leaks:
-
When a user writes "false" and the current mode is already manual, the function returns early without freeing the freshly allocated new_wi_state.
-
When a user writes "true", old_wi_state stays NULL because the fetch is skipped entirely. The old state is then overwritten by rcu_assign_pointer() but never freed, since the cleanup path is gated on old_wi_state being non-NULL. A user can trigger this repeatedly by writing "1" in a loop.
Fix both leaks by moving the old_wi_state fetch before the input check, making it unconditional. This also allows a unified early return for both "true" and "false" when the requested mode matches the current mode.
Reviewed by: Donet Tom donettom@linux.ibm.com
{
"affected": [],
"aliases": [
"CVE-2026-46042"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix memory leaks in weighted_interleave_auto_store()\n\nweighted_interleave_auto_store() fetches old_wi_state inside the if\n(!input) block only. This causes two memory leaks:\n\n1. When a user writes \"false\" and the current mode is already manual,\n the function returns early without freeing the freshly allocated\n new_wi_state.\n\n2. When a user writes \"true\", old_wi_state stays NULL because the\n fetch is skipped entirely. The old state is then overwritten by\n rcu_assign_pointer() but never freed, since the cleanup path is\n gated on old_wi_state being non-NULL. A user can trigger this\n repeatedly by writing \"1\" in a loop.\n\nFix both leaks by moving the old_wi_state fetch before the input check,\nmaking it unconditional. This also allows a unified early return for both\n\"true\" and \"false\" when the requested mode matches the current mode.\n\nReviewed by: Donet Tom \u003cdonettom@linux.ibm.com\u003e",
"id": "GHSA-pmw2-6gh9-j59g",
"modified": "2026-06-16T15:33:41Z",
"published": "2026-05-27T15:33:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46042"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39caa9ca863f96b3d00447c5aa200cabda489856"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fae274ce0e3109cbbc4c18b354eaace1f0af7d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c42a7efb9060d89b72708ffaf255d0002c2164a7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PMWC-7QQ9-MJ6G
Vulnerability from github – Published: 2024-12-29 12:30 – Updated: 2025-01-08 00:30In the Linux kernel, the following vulnerability has been resolved:
vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()
Fix an unwind issue in mlx5vf_add_migration_pages().
If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak.
Any pages successfully added to the SG table will be freed as part of mlx5vf_free_data_buffer().
{
"affected": [],
"aliases": [
"CVE-2024-56742"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T12:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()\n\nFix an unwind issue in mlx5vf_add_migration_pages().\n\nIf a set of pages is allocated but fails to be added to the SG table,\nthey need to be freed to prevent a memory leak.\n\nAny pages successfully added to the SG table will be freed as part of\nmlx5vf_free_data_buffer().",
"id": "GHSA-pmwc-7qq9-mj6g",
"modified": "2025-01-08T00:30:48Z",
"published": "2024-12-29T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56742"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22e87bf3f77c18f5982c19ffe2732ef0c7a25f16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/769fe4ce444b646b0bf6ac308de80686c730c7df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c44f1b2ddfa81c8d7f8e9b6bc76c427bc00e69d5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PP3M-QP57-R498
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-14 18:31In 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] [ 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---
{
"affected": [],
"aliases": [
"CVE-2024-56542"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix a memleak issue when driver is removed\n\nRunning \"modprobe amdgpu\" the second time (followed by a modprobe -r\namdgpu) causes a call trace like:\n\n[ 845.212163] Memory manager not clean during takedown.\n[ 845.212170] WARNING: CPU: 4 PID: 2481 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x2b/0x40\n[ 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\n[ 845.212284] wmi [last unloaded: amddrm_ttm_helper(OE)]\n[ 845.212290] CPU: 4 PID: 2481 Comm: modprobe Tainted: G W OE 6.8.0-31-generic #31-Ubuntu\n[ 845.212296] RIP: 0010:drm_mm_takedown+0x2b/0x40\n[ 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 \u003c0f\u003e 0b 5d 31 c0 31 ff e9 74 2e 86 00 66 0f 1f 84 00 00 00 00 00 90\n[ 845.212302] RSP: 0018:ffffb11302127ae0 EFLAGS: 00010246\n[ 845.212305] RAX: 0000000000000000 RBX: ffff92aa5020fc08 RCX: 0000000000000000\n[ 845.212307] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 845.212309] RBP: ffffb11302127ae0 R08: 0000000000000000 R09: 0000000000000000\n[ 845.212310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004\n[ 845.212312] R13: ffff92aa50200000 R14: ffff92aa5020fb10 R15: ffff92aa5020faa0\n[ 845.212313] FS: 0000707dd7c7c080(0000) GS:ffff92b93de00000(0000) knlGS:0000000000000000\n[ 845.212316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 845.212318] CR2: 00007d48b0aee200 CR3: 0000000115a58000 CR4: 0000000000f50ef0\n[ 845.212320] PKRU: 55555554\n[ 845.212321] Call Trace:\n[ 845.212323] \u003cTASK\u003e\n[ 845.212328] ? show_regs+0x6d/0x80\n[ 845.212333] ? __warn+0x89/0x160\n[ 845.212339] ? drm_mm_takedown+0x2b/0x40\n[ 845.212344] ? report_bug+0x17e/0x1b0\n[ 845.212350] ? handle_bug+0x51/0xa0\n[ 845.212355] ? exc_invalid_op+0x18/0x80\n[ 845.212359] ? asm_exc_invalid_op+0x1b/0x20\n[ 845.212366] ? drm_mm_takedown+0x2b/0x40\n[ 845.212371] amdgpu_gtt_mgr_fini+0xa9/0x130 [amdgpu]\n[ 845.212645] amdgpu_ttm_fini+0x264/0x340 [amdgpu]\n[ 845.212770] amdgpu_bo_fini+0x2e/0xc0 [amdgpu]\n[ 845.212894] gmc_v12_0_sw_fini+0x2a/0x40 [amdgpu]\n[ 845.213036] amdgpu_device_fini_sw+0x11a/0x590 [amdgpu]\n[ 845.213159] amdgpu_driver_release_kms+0x16/0x40 [amdgpu]\n[ 845.213302] devm_drm_dev_init_release+0x5e/0x90\n[ 845.213305] devm_action_release+0x12/0x30\n[ 845.213308] release_nodes+0x42/0xd0\n[ 845.213311] devres_release_all+0x97/0xe0\n[ 845.213314] device_unbind_cleanup+0x12/0x80\n[ 845.213317] device_release_driver_internal+0x230/0x270\n[ 845.213319] ? srso_alias_return_thunk+0x5/0xfbef5\n\nThis is caused by lost memory during early init phase. First time driver\nis removed, memory is freed but when second time the driver is inserted,\nVBIOS dmub is not active, since the PSP policy is to retain the driver\nloaded version on subsequent warm boots. Hence, communication with VBIOS\nDMUB fails.\n\nFix this by aborting further comm\n---truncated---",
"id": "GHSA-pp3m-qp57-r498",
"modified": "2025-01-14T18:31:54Z",
"published": "2024-12-27T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56542"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5860c637513036a6ffc130950ea98676b591b47c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4f36e5fd800de7db74c1c4e62baf24a091a5ff6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e51cbe40b77a32e8698ad8b9582e5b4fce6da364"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PP49-8W45-9FXR
Vulnerability from github – Published: 2024-02-27 21:31 – Updated: 2024-04-10 21:30In the Linux kernel, the following vulnerability has been resolved:
media: dvbdev: Fix memory leak in dvb_media_device_free()
dvb_media_device_free() is leaking memory. Free dvbdev->adapter->conn
before setting it to NULL, as documented in include/media/media-device.h:
"The media_entity instance itself must be freed explicitly by the driver
if required."
{
"affected": [],
"aliases": [
"CVE-2020-36777"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-27T19:04:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvbdev: Fix memory leak in dvb_media_device_free()\n\ndvb_media_device_free() is leaking memory. Free `dvbdev-\u003eadapter-\u003econn`\nbefore setting it to NULL, as documented in include/media/media-device.h:\n\"The media_entity instance itself must be freed explicitly by the driver\nif required.\"",
"id": "GHSA-pp49-8w45-9fxr",
"modified": "2024-04-10T21:30:28Z",
"published": "2024-02-27T21:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36777"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06854b943e0571ccbd7ad0a529babed1a98ff275"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32168ca1f123316848fffb85d059860adf3c409f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43263fd43083e412311fa764cd04a727b0c6a749"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9185b3b1c143b8da409c19ac5a785aa18d67a81b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ad15e214fcd73694ea51967d86055f47b802066"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf9a40ae8d722f281a2721779595d6df1c33a0bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd89f79be5d553c78202f686e8e4caa5fbe94e98"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cede24d13be6c2a62be6d7ceea63c2719b0cfa82"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PP5F-F2RV-Q3VX
Vulnerability from github – Published: 2025-03-18 21:32 – Updated: 2025-03-18 21:32In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested.
This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30
{
"affected": [],
"aliases": [
"CVE-2022-49209"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:58Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full\n\nIf tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()\nreturns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial\nmemory has been alloced by sk_msg_alloc(), that is, msg_tx-\u003esg.size is\ngreater than osize after sk_msg_alloc(), memleak occurs. To fix we use\nsk_msg_trim() to release the allocated memory, then goto wait for memory.\n\nOther call paths of sk_msg_alloc() have the similar issue, such as\ntls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),\nas Cong Wang suggested.\n\nThis issue can cause the following info:\nWARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0\nCall Trace:\n \u003cTASK\u003e\n inet_csk_destroy_sock+0x55/0x110\n __tcp_close+0x279/0x470\n tcp_close+0x1f/0x60\n inet_release+0x3f/0x80\n __sock_release+0x3d/0xb0\n sock_close+0x11/0x20\n __fput+0x92/0x250\n task_work_run+0x6a/0xa0\n do_exit+0x33b/0xb60\n do_group_exit+0x2f/0xa0\n get_signal+0xb6/0x950\n arch_do_signal_or_restart+0xac/0x2a0\n exit_to_user_mode_prepare+0xa9/0x200\n syscall_exit_to_user_mode+0x12/0x30\n do_syscall_64+0x46/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n \u003c/TASK\u003e\n\nWARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260\nCall Trace:\n \u003cTASK\u003e\n __sk_destruct+0x24/0x1f0\n sk_psock_destroy+0x19b/0x1c0\n process_one_work+0x1b3/0x3c0\n kthread+0xe6/0x110\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e",
"id": "GHSA-pp5f-f2rv-q3vx",
"modified": "2025-03-18T21:32:00Z",
"published": "2025-03-18T21:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49209"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d03722c34d9603df325f67c6d30dc1b7b3c6067"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0b85dfc6f01d26808e2576c6537c131b590e270"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de3a8d8fab0710186f7864ec812836d8d70da3c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f677328f05f52d535cbdc15cb04476db49477eb4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PPGM-9RRH-GX75
Vulnerability from github – Published: 2021-12-24 00:00 – Updated: 2021-12-30 00:00A memory leak vulnerability was found in Privoxy when handling errors.
{
"affected": [],
"aliases": [
"CVE-2021-44542"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-23T20:15:00Z",
"severity": "HIGH"
},
"details": "A memory leak vulnerability was found in Privoxy when handling errors.",
"id": "GHSA-ppgm-9rrh-gx75",
"modified": "2021-12-30T00:00:27Z",
"published": "2021-12-24T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44542"
},
{
"type": "WEB",
"url": "https://www.privoxy.org/3.0.33/user-manual/whatsnew.html,"
},
{
"type": "WEB",
"url": "https://www.privoxy.org/gitweb/?p=privoxy.git;a=commit;h=c48d1d6d08"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PPRP-5VM4-JH25
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48A kernel memory leak in QFX10002-32Q, QFX10002-60C, QFX10002-72Q, QFX10008, QFX10016 devices Flexible PIC Concentrators (FPCs) on Juniper Networks Junos OS allows an attacker to send genuine packets destined to the device to cause a Denial of Service (DoS) to the device. On QFX10002-32Q, QFX10002-60C, QFX10002-72Q devices the device will crash and restart. On QFX10008, QFX10016 devices, depending on the number of FPCs involved in an attack, one more more FPCs may crash and traffic through the device may be degraded in other ways, until the attack traffic stops. A reboot is required to restore service and clear the kernel memory. Continued receipt and processing of these genuine packets will create a sustained Denial of Service (DoS) condition. On QFX10008, QFX10016 devices, an indicator of compromise may be the existence of DCPFE core files. You can also monitor PFE memory utilization for incremental growth: user@qfx-RE:0% cprod -A fpc0 -c "show heap 0" | grep -i ke 0 3788a1b0 3221225048 2417120656 804104392 24 Kernel user@qfx-RE:0% cprod -A fpc0 -c "show heap 0" | grep -i ke 0 3788a1b0 3221225048 2332332200 888892848 27 Kernel This issue affects: Juniper Networks Junos OS on QFX10002-32Q, QFX10002-60C, QFX10002-72Q, QFX10008, QFX10016: 16.1 versions 16.1R1 and above prior to 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R3-S2; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R3; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R3; 20.1 versions prior to 20.1R2. This issue does not affect releases prior to Junos OS 16.1R1. This issue does not affect EX Series devices. This issue does not affect Junos OS Evolved.
{
"affected": [],
"aliases": [
"CVE-2021-0272"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-22T20:15:00Z",
"severity": "MODERATE"
},
"details": "A kernel memory leak in QFX10002-32Q, QFX10002-60C, QFX10002-72Q, QFX10008, QFX10016 devices Flexible PIC Concentrators (FPCs) on Juniper Networks Junos OS allows an attacker to send genuine packets destined to the device to cause a Denial of Service (DoS) to the device. On QFX10002-32Q, QFX10002-60C, QFX10002-72Q devices the device will crash and restart. On QFX10008, QFX10016 devices, depending on the number of FPCs involved in an attack, one more more FPCs may crash and traffic through the device may be degraded in other ways, until the attack traffic stops. A reboot is required to restore service and clear the kernel memory. Continued receipt and processing of these genuine packets will create a sustained Denial of Service (DoS) condition. On QFX10008, QFX10016 devices, an indicator of compromise may be the existence of DCPFE core files. You can also monitor PFE memory utilization for incremental growth: user@qfx-RE:0% cprod -A fpc0 -c \"show heap 0\" | grep -i ke 0 3788a1b0 3221225048 2417120656 804104392 24 Kernel user@qfx-RE:0% cprod -A fpc0 -c \"show heap 0\" | grep -i ke 0 3788a1b0 3221225048 2332332200 888892848 27 Kernel This issue affects: Juniper Networks Junos OS on QFX10002-32Q, QFX10002-60C, QFX10002-72Q, QFX10008, QFX10016: 16.1 versions 16.1R1 and above prior to 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R3-S2; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R3; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R3; 20.1 versions prior to 20.1R2. This issue does not affect releases prior to Junos OS 16.1R1. This issue does not affect EX Series devices. This issue does not affect Junos OS Evolved.",
"id": "GHSA-pprp-5vm4-jh25",
"modified": "2022-05-24T17:48:15Z",
"published": "2022-05-24T17:48:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0272"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11163"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/KB32854"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PPRX-8WQF-9H75
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: lpc32xx_udc: 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.
{
"affected": [],
"aliases": [
"CVE-2023-53418"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: lpc32xx_udc: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.",
"id": "GHSA-pprx-8wqf-9h75",
"modified": "2025-12-11T15:30:30Z",
"published": "2025-09-18T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53418"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/036ada6ca9eea926abc0b0ef550b10488d66d4d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72c25eb9ae4993ccac4821354ff34eb1f32e4781"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a5fdd8660174a8056de57d1fdce3a7e9f77f60e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3965acaf3739fde9d74ad82979b46d37c6c208f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PQ3F-WH3M-P798
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-19 15:31In the Linux kernel, the following vulnerability has been resolved:
ath11k: fix missing skb drop on htc_tx_completion error
On htc_tx_completion error the skb is not dropped. This is wrong since the completion_handler logic expect the skb to be consumed anyway even when an error is triggered. Not freeing the skb on error is a memory leak since the skb won't be freed anywere else. Correctly free the packet on eid >= ATH11K_HTC_EP_COUNT before returning.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
{
"affected": [],
"aliases": [
"CVE-2022-50186"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:49Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: fix missing skb drop on htc_tx_completion error\n\nOn htc_tx_completion error the skb is not dropped. This is wrong since\nthe completion_handler logic expect the skb to be consumed anyway even\nwhen an error is triggered. Not freeing the skb on error is a memory\nleak since the skb won\u0027t be freed anywere else. Correctly free the\npacket on eid \u003e= ATH11K_HTC_EP_COUNT before returning.\n\nTested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1",
"id": "GHSA-pq3f-wh3m-p798",
"modified": "2025-11-19T15:31:29Z",
"published": "2025-06-18T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50186"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f1483361585ae7556492f50f83f038bbdf8c294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dda25326839d6e6b1fe59e79616149e44ea4eaa4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5646fe3b7ef739c392e59da7db6adf5e1fdef42"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-41
Strategy: Libraries or Frameworks
- Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
- For example, glibc in Linux provides protection against free of invalid pointers.
- When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
- To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.
Mitigation
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Mitigation
Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.
No CAPEC attack patterns related to this CWE.