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-73CW-J3WH-RF6G
Vulnerability from github – Published: 2025-05-08 09:30 – Updated: 2025-11-10 18:30In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix kmemleak warning for percpu hashmap
Vlad Poenaru reported the following kmemleak issue:
unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): (void __percpu *)(l->key + key_size) = pptr;
Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.
In htab_map_alloc(), we already have
htab->elem_size = sizeof(struct htab_elem) +
round_up(htab->map.key_size, 8);
if (percpu)
htab->elem_size += sizeof(void *);
else
htab->elem_size += round_up(htab->map.value_size, 8);
So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.
The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.
{
"affected": [],
"aliases": [
"CVE-2025-37807"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-08T07:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n unreferenced object 0x606fd7c44ac8 (size 32):\n backtrace (crc 0):\n pcpu_alloc_noprof+0x730/0xeb0\n bpf_map_alloc_percpu+0x69/0xc0\n prealloc_init+0x9d/0x1b0\n htab_map_alloc+0x363/0x510\n map_create+0x215/0x3a0\n __sys_bpf+0x16b/0x3e0\n __x64_sys_bpf+0x18/0x20\n do_syscall_64+0x7b/0x150\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n *(void __percpu **)(l-\u003ekey + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won\u0027t detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n htab-\u003eelem_size = sizeof(struct htab_elem) +\n round_up(htab-\u003emap.key_size, 8);\n if (percpu)\n htab-\u003eelem_size += sizeof(void *);\n else\n htab-\u003eelem_size += round_up(htab-\u003emap.value_size, 8);\n\nSo storing pptr with 8-byte alignment won\u0027t cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n 1. Enable CONFIG_DEBUG_KMEMLEAK config\n 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n The purpose is to keep map available so kmemleak can be detected.\n 3. run \u0027./test_progs -t for_each/hash_map \u0026\u0027 and a kmemleak should be reported.",
"id": "GHSA-73cw-j3wh-rf6g",
"modified": "2025-11-10T18:30:31Z",
"published": "2025-05-08T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37807"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe"
}
],
"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-73GQ-MXP2-9HWR
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-03 18:30In the Linux kernel, the following vulnerability has been resolved:
driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()
The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it.
{
"affected": [],
"aliases": [
"CVE-2023-53267"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T08:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()\n\nThe kfree() should be called when memory fails to be allocated for\ncb_data in xlnx_add_cb_for_notify_event(), otherwise there will be\na memory leak, so add kfree() to fix it.",
"id": "GHSA-73gq-mxp2-9hwr",
"modified": "2025-12-03T18:30:20Z",
"published": "2025-09-16T15:32:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53267"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bea534991b9b35c41848a397666ada436456beb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dfb6c784e385f6e61994bb4e16ce12f3e4940be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d35290addcbac94b076babe0a798a8c043421812"
}
],
"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-73J8-R39C-JXP6
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-24 18:31In the Linux kernel, the following vulnerability has been resolved:
block: release rq qos structures for queue without disk
blkcg_init_queue() may add rq qos structures to request queue, previously blk_cleanup_queue() calls rq_qos_exit() to release them, but commit 8e141f9eb803 ("block: drain file system I/O on del_gendisk") moves rq_qos_exit() into del_gendisk(), so memory leak is caused because queues may not have disk, such as un-present scsi luns, nvme admin queue, ...
Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back.
BTW, v5.18 won't need this patch any more since we move blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release handler, and patches have been in for-5.18/block.
{
"affected": [],
"aliases": [
"CVE-2022-48846"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: release rq qos structures for queue without disk\n\nblkcg_init_queue() may add rq qos structures to request queue, previously\nblk_cleanup_queue() calls rq_qos_exit() to release them, but commit\n8e141f9eb803 (\"block: drain file system I/O on del_gendisk\")\nmoves rq_qos_exit() into del_gendisk(), so memory leak is caused\nbecause queues may not have disk, such as un-present scsi luns, nvme\nadmin queue, ...\n\nFixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back.\n\nBTW, v5.18 won\u0027t need this patch any more since we move\nblkcg_init_queue()/blkcg_exit_queue() into disk allocation/release\nhandler, and patches have been in for-5.18/block.",
"id": "GHSA-73j8-r39c-jxp6",
"modified": "2024-07-24T18:31:16Z",
"published": "2024-07-16T15:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48846"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b"
}
],
"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-73JC-99JJ-CH5V
Vulnerability from github – Published: 2026-04-03 18:31 – Updated: 2026-05-20 15:35In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix cache_request leak in cache_release
When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request.
In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup.
The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up.
Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.
{
"affected": [],
"aliases": [
"CVE-2026-31400"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T16:16:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix cache_request leak in cache_release\n\nWhen a reader\u0027s file descriptor is closed while in the middle of reading\na cache_request (rp-\u003eoffset != 0), cache_release() decrements the\nrequest\u0027s readers count but never checks whether it should free the\nrequest.\n\nIn cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the\ncache_request is removed from the queue and freed along with its buffer\nand cache_head reference. cache_release() lacks this cleanup.\n\nThe only other path that frees requests with readers == 0 is\ncache_dequeue(), but it runs only when CACHE_PENDING transitions from\nset to clear. If that transition already happened while readers was\nstill non-zero, cache_dequeue() will have skipped the request, and no\nsubsequent call will clean it up.\n\nAdd the same cleanup logic from cache_read() to cache_release(): after\ndecrementing readers, check if it reached 0 with CACHE_PENDING clear,\nand if so, dequeue and free the cache_request.",
"id": "GHSA-73jc-99jj-ch5v",
"modified": "2026-05-20T15:35:22Z",
"published": "2026-04-03T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31400"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17ad31b3a43b72aec3a3d83605891e1397d0d065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dfedb293943e491379c9302b428e6f920a73d12"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/301670dcd098c1fe5c2fe90fb3c7a8f4814d2351"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/373457de14281c1fc7cace6fc4c8a267fc176673"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41f6ba6c98a618043d2cd71030bf9a752dfab8b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bcd5e318876ac638c8ceade7a648e76ac8c48e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be5c35960e5ead70862736161836e2d1bc7352dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f18c1f2a88ca91357916997cdb0f7adaf14fc497"
}
],
"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-7427-8GGF-G35C
Vulnerability from github – Published: 2025-08-11 06:30 – Updated: 2025-08-11 06:30in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through missing release of memory.
{
"affected": [],
"aliases": [
"CVE-2025-24844"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-11T04:15:34Z",
"severity": "LOW"
},
"details": "in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through missing release of memory.",
"id": "GHSA-7427-8ggf-g35c",
"modified": "2025-08-11T06:30:30Z",
"published": "2025-08-11T06:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24844"
},
{
"type": "WEB",
"url": "https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2025/2025-07.md"
}
],
"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-74MQ-WR7W-WWVW
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-23 15:31In the Linux kernel, the following vulnerability has been resolved:
sctp: fix kernel-infoleak for SCTP sockets
syzbot reported a kernel infoleak [1] of 4 bytes.
After analysis, it turned out r->idiag_expires is not initialized if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
Make sure to clear idiag_timer/idiag_retrans/idiag_expires and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
Bytes 68-71 of 2508 are uninitialized Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0
CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
{
"affected": [],
"aliases": [
"CVE-2022-48855"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:12Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix kernel-infoleak for SCTP sockets\n\nsyzbot reported a kernel infoleak [1] of 4 bytes.\n\nAfter analysis, it turned out r-\u003eidiag_expires is not initialized\nif inet_sctp_diag_fill() calls inet_diag_msg_common_fill()\n\nMake sure to clear idiag_timer/idiag_retrans/idiag_expires\nand let inet_diag_msg_sctpasoc_fill() fill them again if needed.\n\n[1]\n\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:154 [inline]\n _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668\n copy_to_iter include/linux/uio.h:162 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425\n skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533\n skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]\n netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977\n sock_recvmsg_nosec net/socket.c:948 [inline]\n sock_recvmsg net/socket.c:966 [inline]\n __sys_recvfrom+0x795/0xa10 net/socket.c:2097\n __do_sys_recvfrom net/socket.c:2115 [inline]\n __se_sys_recvfrom net/socket.c:2111 [inline]\n __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:737 [inline]\n slab_alloc_node mm/slub.c:3247 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1158 [inline]\n netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248\n __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277\n netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]\n netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343\n netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919\n sock_sendmsg_nosec net/socket.c:705 [inline]\n sock_sendmsg net/socket.c:725 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1061\n do_iter_readv_writev+0xa7f/0xc70\n do_iter_write+0x52c/0x1500 fs/read_write.c:851\n vfs_writev fs/read_write.c:924 [inline]\n do_writev+0x645/0xe00 fs/read_write.c:967\n __do_sys_writev fs/read_write.c:1040 [inline]\n __se_sys_writev fs/read_write.c:1037 [inline]\n __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBytes 68-71 of 2508 are uninitialized\nMemory access of size 2508 starts at ffff888114f9b000\nData copied to user address 00007f7fe09ff2e0\n\nCPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011",
"id": "GHSA-74mq-wr7w-wwvw",
"modified": "2024-07-23T15:31:08Z",
"published": "2024-07-16T15:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48855"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1502f15b9f29c41883a6139f2923523873282a83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/633593a808980f82d251d0ca89730d8bb8b0220c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c5836c76a08"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-755W-2H7X-XVJ6
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-03-06 12:30In the Linux kernel, the following vulnerability has been resolved:
ceph: fix memory leak in ceph_mds_auth_match()
We now free the temporary target path substring allocation on every possible branch, instead of omitting the default branch. In some cases, a memory leak occured, which could rapidly crash the system (depending on how many file accesses were attempted).
This was detected in production because it caused a continuous memory growth, eventually triggering kernel OOM and completely hard-locking the kernel.
Relevant kmemleak stacktrace:
unreferenced object 0xffff888131e69900 (size 128):
comm "git", pid 66104, jiffies 4295435999
hex dump (first 32 bytes):
76 6f 6c 75 6d 65 73 2f 63 6f 6e 74 61 69 6e 65 volumes/containe
72 73 2f 67 69 74 65 61 2f 67 69 74 65 61 2f 67 rs/gitea/gitea/g
backtrace (crc 2f3bb450):
[<ffffffffaa68fb49>] __kmalloc_noprof+0x359/0x510
[<ffffffffc32bf1df>] ceph_mds_check_access+0x5bf/0x14e0 [ceph]
[<ffffffffc3235722>] ceph_open+0x312/0xd80 [ceph]
[<ffffffffaa7dd786>] do_dentry_open+0x456/0x1120
[<ffffffffaa7e3729>] vfs_open+0x79/0x360
[<ffffffffaa832875>] path_openat+0x1de5/0x4390
[<ffffffffaa834fcc>] do_filp_open+0x19c/0x3c0
[<ffffffffaa7e44a1>] do_sys_openat2+0x141/0x180
[<ffffffffaa7e4945>] __x64_sys_open+0xe5/0x1a0
[<ffffffffac2cc2f7>] do_syscall_64+0xb7/0x210
[<ffffffffac400130>] entry_SYSCALL_64_after_hwframe+0x77/0x7f
It can be triggered by mouting a subdirectory of a CephFS filesystem, and then trying to access files on this subdirectory with an auth token using a path-scoped capability:
$ ceph auth get client.services
[client.services]
key = REDACTED
caps mds = "allow rw fsname=cephfs path=/volumes/"
caps mon = "allow r fsname=cephfs"
caps osd = "allow rw tag cephfs data=cephfs"
$ cat /proc/self/mounts
services@[REDACTED].cephfs=/volumes/containers /ceph/containers ceph rw,noatime,name=services,secret=<hidden>,ms_mode=prefer-crc,mount_timeout=300,acl,mon_addr=[REDACTED]:3300,recover_session=clean 0 0
$ seq 1 1000000 | xargs -P32 --replace={} touch /ceph/containers/file-{} && \
seq 1 1000000 | xargs -P32 --replace={} cat /ceph/containers/file-{}
[ idryomov: combine if statements, rename rc to path_matched and make it a bool, formatting ]
{
"affected": [],
"aliases": [
"CVE-2025-21737"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T03:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix memory leak in ceph_mds_auth_match()\n\nWe now free the temporary target path substring allocation on every\npossible branch, instead of omitting the default branch. In some\ncases, a memory leak occured, which could rapidly crash the system\n(depending on how many file accesses were attempted).\n\nThis was detected in production because it caused a continuous memory\ngrowth, eventually triggering kernel OOM and completely hard-locking\nthe kernel.\n\nRelevant kmemleak stacktrace:\n\n unreferenced object 0xffff888131e69900 (size 128):\n comm \"git\", pid 66104, jiffies 4295435999\n hex dump (first 32 bytes):\n 76 6f 6c 75 6d 65 73 2f 63 6f 6e 74 61 69 6e 65 volumes/containe\n 72 73 2f 67 69 74 65 61 2f 67 69 74 65 61 2f 67 rs/gitea/gitea/g\n backtrace (crc 2f3bb450):\n [\u003cffffffffaa68fb49\u003e] __kmalloc_noprof+0x359/0x510\n [\u003cffffffffc32bf1df\u003e] ceph_mds_check_access+0x5bf/0x14e0 [ceph]\n [\u003cffffffffc3235722\u003e] ceph_open+0x312/0xd80 [ceph]\n [\u003cffffffffaa7dd786\u003e] do_dentry_open+0x456/0x1120\n [\u003cffffffffaa7e3729\u003e] vfs_open+0x79/0x360\n [\u003cffffffffaa832875\u003e] path_openat+0x1de5/0x4390\n [\u003cffffffffaa834fcc\u003e] do_filp_open+0x19c/0x3c0\n [\u003cffffffffaa7e44a1\u003e] do_sys_openat2+0x141/0x180\n [\u003cffffffffaa7e4945\u003e] __x64_sys_open+0xe5/0x1a0\n [\u003cffffffffac2cc2f7\u003e] do_syscall_64+0xb7/0x210\n [\u003cffffffffac400130\u003e] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIt can be triggered by mouting a subdirectory of a CephFS filesystem,\nand then trying to access files on this subdirectory with an auth token\nusing a path-scoped capability:\n\n $ ceph auth get client.services\n [client.services]\n key = REDACTED\n caps mds = \"allow rw fsname=cephfs path=/volumes/\"\n caps mon = \"allow r fsname=cephfs\"\n caps osd = \"allow rw tag cephfs data=cephfs\"\n\n $ cat /proc/self/mounts\n services@[REDACTED].cephfs=/volumes/containers /ceph/containers ceph rw,noatime,name=services,secret=\u003chidden\u003e,ms_mode=prefer-crc,mount_timeout=300,acl,mon_addr=[REDACTED]:3300,recover_session=clean 0 0\n\n $ seq 1 1000000 | xargs -P32 --replace={} touch /ceph/containers/file-{} \u0026\u0026 \\\n seq 1 1000000 | xargs -P32 --replace={} cat /ceph/containers/file-{}\n\n[ idryomov: combine if statements, rename rc to path_matched and make\n it a bool, formatting ]",
"id": "GHSA-755w-2h7x-xvj6",
"modified": "2025-03-06T12:30:41Z",
"published": "2025-02-27T03:34:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21737"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/146109fe936ac07f8f60cd6267543688985b96bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b6086c5efe5c7bd6e0eb440d96c26ca0d20d9d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b7d93db450e9d8ead80d75e2a303248f1528c35"
}
],
"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-7576-JC69-87M3
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
media: i2c: et8ek8: Don't strip remove function when driver is builtin
Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.
This also fixes a W=1 modpost warning:
WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)
{
"affected": [],
"aliases": [
"CVE-2024-38611"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:20Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: et8ek8: Don\u0027t strip remove function when driver is builtin\n\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\n\nThis also fixes a W=1 modpost warning:\n\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u003e et8ek8_remove (section: .exit.text)",
"id": "GHSA-7576-jc69-87m3",
"modified": "2025-11-03T21:31:09Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38611"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04d1086a62ac492ebb6bb0c94c1c8cb55f5d1f36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/904db2ba44ae60641b6378c5013254d09acf5e80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/963523600d9f1e36bc35ba774c2493d6baa4dd8f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1a3803e5bb91c13e9ad582003e4288f67f06cd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ece3fc1c10197052044048bea4f13cfdcf25b416"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-759C-P77C-J97R
Vulnerability from github – Published: 2024-03-04 21:31 – Updated: 2025-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()
The wrong goto label was used for the error case and missed cleanup of the pkt allocation.
Addresses-Coverity-ID: 1493352 ("Resource leak")
{
"affected": [],
"aliases": [
"CVE-2021-47104"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-04T19:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/qib: Fix memory leak in qib_user_sdma_queue_pkts()\n\nThe wrong goto label was used for the error case and missed cleanup of the\npkt allocation.\n\nAddresses-Coverity-ID: 1493352 (\"Resource leak\")",
"id": "GHSA-759c-p77c-j97r",
"modified": "2025-01-07T18:30:38Z",
"published": "2024-03-04T21:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47104"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0aaec9c5f60754b56f84460ea439b8c5e91f4caa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ced0a3015a95c6a6db45e37250912c4c86697ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76b648063eb36c72dfc0a6896de8a0a7d2c7841c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79dcbd8176152b860028b62f81a635d987365752"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cf6466e00a77b0a914b7b2c28a1fc7947d55e59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aefcc25f3a0cd28a87d11d41d30419a12cd26a34"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bee90911e0138c76ee67458ac0d58b38a3190f65"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d53456492b5d02033c73dfa0f3b94c86337791ba"
}
],
"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-759F-2CPP-X5G6
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 18:30In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly
In iptfs_reassem_cont(), IP-TFS attempts to append data to the new inner packet 'newskb' that is being reassembled. First a zero-copy approach is tried if it succeeds then newskb becomes non-linear.
When a subsequent fragment in the same datagram does not meet the fast-path conditions, a memory copy is performed. It calls skb_put() to append the data and as newskb is non-linear it triggers SKB_LINEAR_ASSERT check.
Oops: invalid opcode: 0000 [#1] SMP NOPTI [...] RIP: 0010:skb_put+0x3c/0x40 [...] Call Trace: iptfs_reassem_cont+0x1ab/0x5e0 [xfrm_iptfs] iptfs_input_ordered+0x2af/0x380 [xfrm_iptfs] iptfs_input+0x122/0x3e0 [xfrm_iptfs] xfrm_input+0x91e/0x1a50 xfrm4_esp_rcv+0x3a/0x110 ip_protocol_deliver_rcu+0x1d7/0x1f0 ip_local_deliver_finish+0xbe/0x1e0 __netif_receive_skb_core.constprop.0+0xb56/0x1120 __netif_receive_skb_list_core+0x133/0x2b0 netif_receive_skb_list_internal+0x1ff/0x3f0 napi_complete_done+0x81/0x220 virtnet_poll+0x9d6/0x116e [virtio_net] __napi_poll.constprop.0+0x2b/0x270 net_rx_action+0x162/0x360 handle_softirqs+0xdc/0x510 __irq_exit_rcu+0xe7/0x110 irq_exit_rcu+0xe/0x20 common_interrupt+0x85/0xa0
Fix this by checking if the skb is non-linear. If it is, linearize it by calling skb_linearize(). As the initial allocation of newskb originally reserved enough tailroom for the entire reassembled packet we do not need to check if we have enough tailroom or extend it.
{
"affected": [],
"aliases": [
"CVE-2026-31517"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly\n\nIn iptfs_reassem_cont(), IP-TFS attempts to append data to the new inner\npacket \u0027newskb\u0027 that is being reassembled. First a zero-copy approach is\ntried if it succeeds then newskb becomes non-linear.\n\nWhen a subsequent fragment in the same datagram does not meet the\nfast-path conditions, a memory copy is performed. It calls skb_put() to\nappend the data and as newskb is non-linear it triggers\nSKB_LINEAR_ASSERT check.\n\n Oops: invalid opcode: 0000 [#1] SMP NOPTI\n [...]\n RIP: 0010:skb_put+0x3c/0x40\n [...]\n Call Trace:\n \u003cIRQ\u003e\n iptfs_reassem_cont+0x1ab/0x5e0 [xfrm_iptfs]\n iptfs_input_ordered+0x2af/0x380 [xfrm_iptfs]\n iptfs_input+0x122/0x3e0 [xfrm_iptfs]\n xfrm_input+0x91e/0x1a50\n xfrm4_esp_rcv+0x3a/0x110\n ip_protocol_deliver_rcu+0x1d7/0x1f0\n ip_local_deliver_finish+0xbe/0x1e0\n __netif_receive_skb_core.constprop.0+0xb56/0x1120\n __netif_receive_skb_list_core+0x133/0x2b0\n netif_receive_skb_list_internal+0x1ff/0x3f0\n napi_complete_done+0x81/0x220\n virtnet_poll+0x9d6/0x116e [virtio_net]\n __napi_poll.constprop.0+0x2b/0x270\n net_rx_action+0x162/0x360\n handle_softirqs+0xdc/0x510\n __irq_exit_rcu+0xe7/0x110\n irq_exit_rcu+0xe/0x20\n common_interrupt+0x85/0xa0\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n\nFix this by checking if the skb is non-linear. If it is, linearize it by\ncalling skb_linearize(). As the initial allocation of newskb originally\nreserved enough tailroom for the entire reassembled packet we do not\nneed to check if we have enough tailroom or extend it.",
"id": "GHSA-759f-2cpp-x5g6",
"modified": "2026-04-28T18:30:29Z",
"published": "2026-04-22T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31517"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b352f83cabfefdaafa806d6471f0eca117dc7d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33a7b36268933c75bdc355e5531951e0ea9f1951"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7fdfe8f6efeb0e1200e22a903f2471539f54522b"
}
],
"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.