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.
2002 vulnerabilities reference this CWE, most recent first.
GHSA-PM4X-JF7F-JMQ6
Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-05-21 00:30In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ...
According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;
After commit 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.
{
"affected": [],
"aliases": [
"CVE-2026-43068"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-05T16:16:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()\n\nThere\u0027s issue as follows:\n...\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): error count since last fsck: 1\nEXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760\nEXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760\n...\n\nAccording to the log analysis, blocks are always requested from the\ncorrupted block group. This may happen as follows:\next4_mb_find_by_goal\n ext4_mb_load_buddy\n ext4_mb_load_buddy_gfp\n ext4_mb_init_cache\n ext4_read_block_bitmap_nowait\n ext4_wait_block_bitmap\n ext4_validate_block_bitmap\n if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))\n return -EFSCORRUPTED; // There\u0027s no logs.\n if (err)\n return err; // Will return error\next4_lock_group(ac-\u003eac_sb, group);\n if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-\u003ebd_info))) // Unreachable\n goto out;\n\nAfter commit 9008a58e5dce (\"ext4: make the bitmap read routines return\nreal error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group\nas corrupt on block bitmap error\") is no real solution for allocating\nblocks from corrupted block groups. This is because if\n\u0027EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-\u003ebd_info)\u0027 is true, then\n\u0027ext4_mb_load_buddy()\u0027 may return an error. This means that the block\nallocation will fail.\nTherefore, check block group if corrupted when ext4_mb_load_buddy()\nreturns error.",
"id": "GHSA-pm4x-jf7f-jmq6",
"modified": "2026-05-21T00:30:26Z",
"published": "2026-05-05T18:33:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43068"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b84571c886719823d537f05f4f07cad6357c4b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1895f7904be71c48f1e6f338b28f24dabd6b8aeb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c0d7c4cde38a887c6d74e0c89ddb25226943c78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d31a5073f86a177edf44015e0dedb0c47cfd6d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46066e3a06647c5b186cc6334409722622d05c44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9370207b36d26e45a8c8ef0500706d37036edd6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fea6b2e250ff48f10d166011b57a8516ae5438c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffc0a282462d45fee5957621be5afa29752f3b6d"
}
],
"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-PM64-F9FF-XC6W
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-14 18:31In 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): [] kmemleak_alloc+0xb8/0xc8 [] __kmalloc_node_track_caller_noprof+0x380/0x474 [] kstrdup+0x70/0xfc [] isofs_parse_param+0x228/0x2c0 [isofs] [] vfs_parse_fs_param+0xf4/0x164 [] vfs_parse_fs_string+0x8c/0xd4 [] vfs_parse_monolithic_sep+0xb0/0xfc [] generic_parse_monolithic+0x30/0x3c [] parse_monolithic_mount_data+0x40/0x4c [] path_mount+0x6c4/0x9ec [] do_mount+0xac/0xc4 [] __arm64_sys_mount+0x16c/0x2b0 [] invoke_syscall+0x7c/0x104 [] el0_svc_common.constprop.1+0xe0/0x104 [] do_el0_svc+0x2c/0x38 [] 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.
{
"affected": [],
"aliases": [
"CVE-2024-56534"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nisofs: avoid memory leak in iocharset\n\nA memleak was found as below:\n\nunreferenced object 0xffff0000d10164d8 (size 8):\n comm \"pool-udisksd\", pid 108217, jiffies 4295408555\n hex dump (first 8 bytes):\n 75 74 66 38 00 cc cc cc utf8....\n backtrace (crc de430d31):\n [\u003cffff800081046e6c\u003e] kmemleak_alloc+0xb8/0xc8\n [\u003cffff8000803e6c3c\u003e] __kmalloc_node_track_caller_noprof+0x380/0x474\n [\u003cffff800080363b74\u003e] kstrdup+0x70/0xfc\n [\u003cffff80007bb3c6a4\u003e] isofs_parse_param+0x228/0x2c0 [isofs]\n [\u003cffff8000804d7f68\u003e] vfs_parse_fs_param+0xf4/0x164\n [\u003cffff8000804d8064\u003e] vfs_parse_fs_string+0x8c/0xd4\n [\u003cffff8000804d815c\u003e] vfs_parse_monolithic_sep+0xb0/0xfc\n [\u003cffff8000804d81d8\u003e] generic_parse_monolithic+0x30/0x3c\n [\u003cffff8000804d8bfc\u003e] parse_monolithic_mount_data+0x40/0x4c\n [\u003cffff8000804b6a64\u003e] path_mount+0x6c4/0x9ec\n [\u003cffff8000804b6e38\u003e] do_mount+0xac/0xc4\n [\u003cffff8000804b7494\u003e] __arm64_sys_mount+0x16c/0x2b0\n [\u003cffff80008002b8dc\u003e] invoke_syscall+0x7c/0x104\n [\u003cffff80008002ba44\u003e] el0_svc_common.constprop.1+0xe0/0x104\n [\u003cffff80008002ba94\u003e] do_el0_svc+0x2c/0x38\n [\u003cffff800081041108\u003e] el0_svc+0x3c/0x1b8\n\nThe opt-\u003eiocharset is freed inside the isofs_fill_super function,\nBut there may be situations where it\u0027s not possible to\nenter this function.\n\nFor example, in the get_tree_bdev_flags function,when\nencountering the situation where \"Can\u0027t mount, would change RO state,\"\nIn such a case, isofs_fill_super will not have the opportunity\nto be called,which means that opt-\u003eiocharset will not have the chance\nto be freed,ultimately leading to a memory leak.\n\nLet\u0027s move the memory freeing of opt-\u003eiocharset into\nisofs_free_fc function.",
"id": "GHSA-pm64-f9ff-xc6w",
"modified": "2025-01-14T18:31:54Z",
"published": "2024-12-27T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b5bbeee4de616a268db77e2f40f19ab010a367b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fbab266ca8000333c966f5b58cb9b9cac658573"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34f090ddb3630a26e5a6b220bf3bfaf5c7b70393"
}
],
"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-PM73-PR98-FPFG
Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()
Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().
{
"affected": [],
"aliases": [
"CVE-2026-23087"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T17:16:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: xen: scsiback: Fix potential memory leak in scsiback_remove()\n\nMemory allocated for struct vscsiblk_info in scsiback_probe() is not\nfreed in scsiback_remove() leading to potential memory leaks on remove,\nas well as in the scsiback_probe() error paths. Fix that by freeing it\nin scsiback_remove().",
"id": "GHSA-pm73-pr98-fpfg",
"modified": "2026-07-14T15:31:39Z",
"published": "2026-02-04T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23087"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24c441f0e24da175d7912095663f526ac480dc4f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32e52b56056daf0f0881fd9254706acf25b4be97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/427b0fb30ddec3bad05dcd73b00718f98c7026d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a975c72429b050c234405668b742cdecc11548e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/901a5f309daba412e2a30364d7ec1492fa11c32c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8bb3ec8d85951a56af0a72d93ccbc2aee42eef9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f86264ec0e2b102fcd49bf3e4f32fee669d482fc"
}
],
"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-PM77-QRWM-74J5
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-17 18:30In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix memory leak inside XPD_TX with mergeable
When we call xdp_convert_buff_to_frame() to get xdpf, if it returns NULL, we should check if xdp_page was allocated by xdp_linearize_page(). If it is newly allocated, it should be freed here alone. Just like any other "goto err_xdp".
{
"affected": [],
"aliases": [
"CVE-2022-50065"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: fix memory leak inside XPD_TX with mergeable\n\nWhen we call xdp_convert_buff_to_frame() to get xdpf, if it returns\nNULL, we should check if xdp_page was allocated by xdp_linearize_page().\nIf it is newly allocated, it should be freed here alone. Just like any\nother \"goto err_xdp\".",
"id": "GHSA-pm77-qrwm-74j5",
"modified": "2025-11-17T18:30:23Z",
"published": "2025-06-18T12:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18e383afbd7047af7b055df6e25436e0ce28f8a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a542bee27c6a57e45c33cbbdc963325fd6493af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3723eab11196475ef83279571b2b0bd0924cf82"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/faafa2a87f697ee537c29446097e1cc3143506fa"
}
],
"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-PM95-MC7J-6JM3
Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-10 18:30In the Linux kernel, the following vulnerability has been resolved:
USB: chipidea: 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-53334"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T17:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: chipidea: 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-pm95-mc7j-6jm3",
"modified": "2025-12-10T18:30:21Z",
"published": "2025-09-16T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4322661af6d7a586a5798ab9aa443f49895b6943"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/610373dd354f3d393aa3bdcab59f55024c16b5e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/972e0682f6e3ee6ecf002657df4aaa511d51dd6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff35f3ea3baba5b81416ac02d005cfbf6dd182fa"
}
],
"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-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"
}
]
}
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.