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-9697-GFV8-47R6
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-05-07 21:30In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix drm_edid leak in amdgpu_dm
[WHAT] When a sink is connected, aconnector->drm_edid was overwritten without freeing the previous allocation, causing a memory leak on resume.
[HOW] Free the previous drm_edid before updating it.
(cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5)
{
"affected": [],
"aliases": [
"CVE-2026-31461"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix drm_edid leak in amdgpu_dm\n\n[WHAT]\nWhen a sink is connected, aconnector-\u003edrm_edid was overwritten without\nfreeing the previous allocation, causing a memory leak on resume.\n\n[HOW]\nFree the previous drm_edid before updating it.\n\n(cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5)",
"id": "GHSA-9697-gfv8-47r6",
"modified": "2026-05-07T21:30:24Z",
"published": "2026-04-22T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31461"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37c2caa167b0b8aca4f74c32404c5288b876a2a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52db857e94b9be4e6315586602b0257d1d2b165a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb95595194e4755b62360aa821f40a79b0953105"
}
],
"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-96C7-C73H-J4WW
Vulnerability from github – Published: 2023-05-23 21:30 – Updated: 2024-03-07 21:30Teeworlds v0.7.5 was discovered to contain memory leaks.
{
"affected": [],
"aliases": [
"CVE-2023-31517"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-23T20:15:09Z",
"severity": "HIGH"
},
"details": "Teeworlds v0.7.5 was discovered to contain memory leaks.",
"id": "GHSA-96c7-c73h-j4ww",
"modified": "2024-03-07T21:30:20Z",
"published": "2023-05-23T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31517"
},
{
"type": "WEB",
"url": "https://gist.github.com/manba-bryant/9ca95d69c65f4d2c55946932c946fb9b"
},
{
"type": "WEB",
"url": "https://www.redpacketsecurity.com/teeworlds-denial-of-service-cve-2023-31517"
},
{
"type": "WEB",
"url": "http://teeworlds.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-96GV-MMP8-MQX5
Vulnerability from github – Published: 2024-12-02 15:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Fix accept_queue memory leak
As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.
vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release
Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30
{
"affected": [],
"aliases": [
"CVE-2024-53119"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-02T14:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio/vsock: Fix accept_queue memory leak\n\nAs the final stages of socket destruction may be delayed, it is possible\nthat virtio_transport_recv_listen() will be called after the accept_queue\nhas been flushed, but before the SOCK_DONE flag has been set. As a result,\nsockets enqueued after the flush would remain unremoved, leading to a\nmemory leak.\n\nvsock_release\n __vsock_release\n lock\n virtio_transport_release\n virtio_transport_close\n schedule_delayed_work(close_work)\n sk_shutdown = SHUTDOWN_MASK\n(!) flush accept_queue\n release\n virtio_transport_recv_pkt\n vsock_find_bound_socket\n lock\n if flag(SOCK_DONE) return\n virtio_transport_recv_listen\n child = vsock_create_connected\n (!) vsock_enqueue_accept(child)\n release\nclose_work\n lock\n virtio_transport_do_close\n set_flag(SOCK_DONE)\n virtio_transport_remove_sock\n vsock_remove_sock\n vsock_remove_bound\n release\n\nIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() during\nsocket destruction.\n\nunreferenced object 0xffff888109e3f800 (size 2040):\n comm \"kworker/5:2\", pid 371, jiffies 4294940105\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............\n backtrace (crc 9e5f4e84):\n [\u003cffffffff81418ff1\u003e] kmem_cache_alloc_noprof+0x2c1/0x360\n [\u003cffffffff81d27aa0\u003e] sk_prot_alloc+0x30/0x120\n [\u003cffffffff81d2b54c\u003e] sk_alloc+0x2c/0x4b0\n [\u003cffffffff81fe049a\u003e] __vsock_create.constprop.0+0x2a/0x310\n [\u003cffffffff81fe6d6c\u003e] virtio_transport_recv_pkt+0x4dc/0x9a0\n [\u003cffffffff81fe745d\u003e] vsock_loopback_work+0xfd/0x140\n [\u003cffffffff810fc6ac\u003e] process_one_work+0x20c/0x570\n [\u003cffffffff810fce3f\u003e] worker_thread+0x1bf/0x3a0\n [\u003cffffffff811070dd\u003e] kthread+0xdd/0x110\n [\u003cffffffff81044fdd\u003e] ret_from_fork+0x2d/0x50\n [\u003cffffffff8100785a\u003e] ret_from_fork_asm+0x1a/0x30",
"id": "GHSA-96gv-mmp8-mqx5",
"modified": "2025-11-04T00:32:09Z",
"published": "2024-12-02T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53119"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2415345042245de7601dcc6eafdbe3a3dcc9e379"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4310902c766e371359e6c6311056ae80b5beeac9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897617a413e0bf1c6380e3b34b2f28f450508549"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/946c7600fa2207cc8d3fbc86a518ec56f98a5813"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7b0ff5a866724c3ad21f2628c22a63336deec3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"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-96J4-P2P4-VFGJ
Vulnerability from github – Published: 2023-09-27 18:30 – Updated: 2024-01-25 18:30A vulnerability in the memory buffer of Cisco Wireless LAN Controller (WLC) AireOS Software could allow an unauthenticated, adjacent attacker to cause memory leaks that could eventually lead to a device reboot.
This vulnerability is due to memory leaks caused by multiple clients connecting under specific conditions. An attacker could exploit this vulnerability by causing multiple wireless clients to attempt to connect to an access point (AP) on an affected device. A successful exploit could allow the attacker to cause the affected device to reboot after a significant amount of time, resulting in a denial of service (DoS) condition.
{
"affected": [],
"aliases": [
"CVE-2023-20251"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-27T18:15:11Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the memory buffer of Cisco Wireless LAN Controller (WLC) AireOS Software could allow an unauthenticated, adjacent attacker to cause memory leaks that could eventually lead to a device reboot.\n\n This vulnerability is due to memory leaks caused by multiple clients connecting under specific conditions. An attacker could exploit this vulnerability by causing multiple wireless clients to attempt to connect to an access point (AP) on an affected device. A successful exploit could allow the attacker to cause the affected device to reboot after a significant amount of time, resulting in a denial of service (DoS) condition.",
"id": "GHSA-96j4-p2p4-vfgj",
"modified": "2024-01-25T18:30:44Z",
"published": "2023-09-27T18:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20251"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cbw-dos-YSmbUqX3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9729-XJVH-4QP8
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback
After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed.
It has been seen after hours of usage of a graphics application or using kmemleak:
unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54
{
"affected": [],
"aliases": [
"CVE-2026-43269"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback\n\nAfter several commits, the slab memory increases. Some drm_crtc_commit\nobjects are not freed. The atomic_destroy_state callback only put the\nframebuffer. Use the __drm_atomic_helper_plane_destroy_state() function\nto put all the objects that are no longer needed.\n\nIt has been seen after hours of usage of a graphics application or using\nkmemleak:\n\nunreferenced object 0xc63a6580 (size 64):\n comm \"egt_basic\", pid 171, jiffies 4294940784\n hex dump (first 32 bytes):\n 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:.\n 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:.\n backtrace (crc c25aa925):\n kmemleak_alloc+0x34/0x3c\n __kmalloc_cache_noprof+0x150/0x1a4\n drm_atomic_helper_setup_commit+0x1e8/0x7bc\n drm_atomic_helper_commit+0x3c/0x15c\n drm_atomic_commit+0xc0/0xf4\n drm_atomic_helper_set_config+0x84/0xb8\n drm_mode_setcrtc+0x32c/0x810\n drm_ioctl+0x20c/0x488\n sys_ioctl+0x14c/0xc20\n ret_fast_syscall+0x0/0x54",
"id": "GHSA-9729-xjvh-4qp8",
"modified": "2026-05-08T21:31:21Z",
"published": "2026-05-06T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43269"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/082271e364a3205598c2e4e6233a9f49ce7941cf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25e832a7830740e72103eb0b527680a4b64bbcb3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e64e78f4a70e3f6ac8fe5a7071f08ffd25a2489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5718d98976ad6b9700e5a6afec67fc47a8a92580"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57fa3487acfa3467405f8506b94682abd96e7393"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d4e91ab97fda64e8cf9c8881cc3b4da026bd849"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec40702029b08ee8d5f5b03303d64a10e74a957b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f12352471061df83a36edf54bbb16284793284e4"
}
],
"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-9748-W7HV-7H34
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix macvlan leak by synchronizing access to mac_filter_hash
This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks.
To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access.
Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future.
Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the mac_filter_hash.
This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.
{
"affected": [],
"aliases": [
"CVE-2024-50041"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix macvlan leak by synchronizing access to mac_filter_hash\n\nThis patch addresses a macvlan leak issue in the i40e driver caused by\nconcurrent access to vsi-\u003emac_filter_hash. The leak occurs when multiple\nthreads attempt to modify the mac_filter_hash simultaneously, leading to\ninconsistent state and potential memory leaks.\n\nTo fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing\nvf-\u003edefault_lan_addr.addr with spin_lock/unlock_bh(\u0026vsi-\u003emac_filter_hash_lock),\nensuring atomic operations and preventing concurrent access.\n\nAdditionally, we add lockdep_assert_held(\u0026vsi-\u003emac_filter_hash_lock) in\ni40e_add_mac_filter() to help catch similar issues in the future.\n\nReproduction steps:\n1. Spawn VFs and configure port vlan on them.\n2. Trigger concurrent macvlan operations (e.g., adding and deleting\n\tportvlan and/or mac filters).\n3. Observe the potential memory leak and inconsistent state in the\n\tmac_filter_hash.\n\nThis synchronization ensures the integrity of the mac_filter_hash and prevents\nthe described leak.",
"id": "GHSA-9748-w7hv-7h34",
"modified": "2025-11-04T00:31:45Z",
"published": "2024-10-21T21:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50041"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/703c4d820b31bcadf465288d5746c53445f02a55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8831abff1bd5b6bc8224f0c0671f46fbd702b5b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a9747288ba0a9ad4f5c9877f18dd245770ad64e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9db6ce9e2738b05a3672aff4d42169cf3bb5a3e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dac6c7b3d33756d6ce09f00a96ea2ecd79fae9fb"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"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-976Q-4667-8RW3
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
staging: wfx: fix an error handling in wfx_init_common()
One error handler of wfx_init_common() return without calling ieee80211_free_hw(hw), which may result in memory leak. And I add one err label to unify the error handler, which is useful for the subsequent changes.
{
"affected": [],
"aliases": [
"CVE-2022-49105"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: wfx: fix an error handling in wfx_init_common()\n\nOne error handler of wfx_init_common() return without calling\nieee80211_free_hw(hw), which may result in memory leak. And I add\none err label to unify the error handler, which is useful for the\nsubsequent changes.",
"id": "GHSA-976q-4667-8rw3",
"modified": "2025-03-14T00:30:49Z",
"published": "2025-03-14T00:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49105"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60f1d3c92dc1ef1026e5b917a329a7fa947da036"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86efcb524ae1889ae73f2a2f0bb7fff2ec757ab0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93498c6e775ae91732a8109dba1bdcd324908f84"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9727912e906762a63c1a667c84731d3427653f88"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab0fed1fa744173433cfd1dbaf9239f200ded650"
}
],
"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-97GJ-Q9FX-VC88
Vulnerability from github – Published: 2024-03-04 18:30 – Updated: 2024-10-31 15:30In the Linux kernel, the following vulnerability has been resolved:
kfence: fix memory leak when cat kfence objects
Hulk robot reported a kmemleak problem:
unreferenced object 0xffff93d1d8cc02e8 (size 248):
comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)
hex dump (first 32 bytes):
00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@..............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
seq_open+0x2a/0x80
full_proxy_open+0x167/0x1e0
do_dentry_open+0x1e1/0x3a0
path_openat+0x961/0xa20
do_filp_open+0xae/0x120
do_sys_openat2+0x216/0x2f0
do_sys_open+0x57/0x80
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
unreferenced object 0xffff93d419854000 (size 4096):
comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)
hex dump (first 32 bytes):
6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0
30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda12-
backtrace:
seq_read_iter+0x313/0x440
seq_read+0x14b/0x1a0
full_proxy_read+0x56/0x80
vfs_read+0xa5/0x1b0
ksys_read+0xa0/0xf0
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
I find that we can easily reproduce this problem with the following commands:
cat /sys/kernel/debug/kfence/objects
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak
The leaked memory is allocated in the stack below:
do_syscall_64
do_sys_open
do_dentry_open
full_proxy_open
seq_open ---> alloc seq_file
vfs_read
full_proxy_read
seq_read
seq_read_iter
traverse ---> alloc seq_buf
And it should have been released in the following process:
do_syscall_64
syscall_exit_to_user_mode
exit_to_user_mode_prepare
task_work_run
____fput
__fput
full_proxy_release ---> free here
However, the release function corresponding to file_operations is not implemented in kfence. As a result, a memory leak occurs. Therefore, the solution to this problem is to implement the corresponding release function.
{
"affected": [],
"aliases": [
"CVE-2021-47089"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-04T18:15:07Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nkfence: fix memory leak when cat kfence objects\n\nHulk robot reported a kmemleak problem:\n\n unreferenced object 0xffff93d1d8cc02e8 (size 248):\n comm \"cat\", pid 23327, jiffies 4624670141 (age 495992.217s)\n hex dump (first 32 bytes):\n 00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@..............\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n seq_open+0x2a/0x80\n full_proxy_open+0x167/0x1e0\n do_dentry_open+0x1e1/0x3a0\n path_openat+0x961/0xa20\n do_filp_open+0xae/0x120\n do_sys_openat2+0x216/0x2f0\n do_sys_open+0x57/0x80\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n unreferenced object 0xffff93d419854000 (size 4096):\n comm \"cat\", pid 23327, jiffies 4624670141 (age 495992.217s)\n hex dump (first 32 bytes):\n 6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0\n 30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda12-\n backtrace:\n seq_read_iter+0x313/0x440\n seq_read+0x14b/0x1a0\n full_proxy_read+0x56/0x80\n vfs_read+0xa5/0x1b0\n ksys_read+0xa0/0xf0\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nI find that we can easily reproduce this problem with the following\ncommands:\n\n\tcat /sys/kernel/debug/kfence/objects\n\techo scan \u003e /sys/kernel/debug/kmemleak\n\tcat /sys/kernel/debug/kmemleak\n\nThe leaked memory is allocated in the stack below:\n\n do_syscall_64\n do_sys_open\n do_dentry_open\n full_proxy_open\n seq_open ---\u003e alloc seq_file\n vfs_read\n full_proxy_read\n seq_read\n seq_read_iter\n traverse ---\u003e alloc seq_buf\n\nAnd it should have been released in the following process:\n\n do_syscall_64\n syscall_exit_to_user_mode\n exit_to_user_mode_prepare\n task_work_run\n ____fput\n __fput\n full_proxy_release ---\u003e free here\n\nHowever, the release function corresponding to file_operations is not\nimplemented in kfence. As a result, a memory leak occurs. Therefore,\nthe solution to this problem is to implement the corresponding release\nfunction.",
"id": "GHSA-97gj-q9fx-vc88",
"modified": "2024-10-31T15:30:57Z",
"published": "2024-03-04T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47089"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0129ab1f268b6cf88825eae819b9b84aa0a85634"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f06c8293d27f6337f907042c602c9c953988c48"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-97HP-6Q9G-5CW2
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-06-23 18:05A memory leak flaw was found in WildFly in all versions up to 21.0.0.Final, where host-controller tries to reconnect in a loop, generating new connections which are not properly closed while not able to connect to domain-controller. This flaw allows an attacker to cause an Out of memory (OOM) issue, leading to a denial of service. The highest threat from this vulnerability is to system availability.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 21.0.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.wildfly:wildfly-dist"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "21.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-25689"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-23T18:05:24Z",
"nvd_published_at": "2020-11-02T21:15:00Z",
"severity": "MODERATE"
},
"details": "A memory leak flaw was found in WildFly in all versions up to 21.0.0.Final, where host-controller tries to reconnect in a loop, generating new connections which are not properly closed while not able to connect to domain-controller. This flaw allows an attacker to cause an Out of memory (OOM) issue, leading to a denial of service. The highest threat from this vulnerability is to system availability.",
"id": "GHSA-97hp-6q9g-5cw2",
"modified": "2022-06-23T18:05:24Z",
"published": "2022-05-24T17:32:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25689"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-25689"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20201123-0006"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uncontrolled Resource Consumption in WildFly"
}
GHSA-97JF-XCMH-9J8R
Vulnerability from github – Published: 2024-05-01 15:30 – Updated: 2024-12-23 15:30In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path
If devm_krealloc() fails, then 'efuse' is leaking. So free it to avoid a leak.
{
"affected": [],
"aliases": [
"CVE-2024-27068"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T13:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path\n\nIf devm_krealloc() fails, then \u0027efuse\u0027 is leaking.\nSo free it to avoid a leak.",
"id": "GHSA-97jf-xcmh-9j8r",
"modified": "2024-12-23T15:30:47Z",
"published": "2024-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27068"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2db869da91afd48e5b9ec76814709be49662b07d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b02197596671800dd934609384b1aca7c6ad218"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a37f3652bee468f879d35fe2da9ede3f1dcbb7be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca93bf607a44c1f009283dac4af7df0d9ae5e357"
}
],
"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.