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-Q8RF-2MP5-5994
Vulnerability from github – Published: 2025-07-25 18:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix wraparounds of sk->sk_rmem_alloc.
Netlink has this pattern in some places
if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc);
, which has the same problem fixed by commit 5a465a0da13e ("udp: Fix multiple wraparounds of sk->sk_rmem_alloc.").
For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition is always false as the two operands are of int.
Then, a single socket can eat as many skb as possible until OOM happens, and we can see multiple wraparounds of sk->sk_rmem_alloc.
Let's fix it by using atomic_add_return() and comparing the two variables as unsigned int.
Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 *
After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576
{
"affected": [],
"aliases": [
"CVE-2025-38465"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T16:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: Fix wraparounds of sk-\u003esk_rmem_alloc.\n\nNetlink has this pattern in some places\n\n if (atomic_read(\u0026sk-\u003esk_rmem_alloc) \u003e sk-\u003esk_rcvbuf)\n \tatomic_add(skb-\u003etruesize, \u0026sk-\u003esk_rmem_alloc);\n\n, which has the same problem fixed by commit 5a465a0da13e (\"udp:\nFix multiple wraparounds of sk-\u003esk_rmem_alloc.\").\n\nFor example, if we set INT_MAX to SO_RCVBUFFORCE, the condition\nis always false as the two operands are of int.\n\nThen, a single socket can eat as many skb as possible until OOM\nhappens, and we can see multiple wraparounds of sk-\u003esk_rmem_alloc.\n\nLet\u0027s fix it by using atomic_add_return() and comparing the two\nvariables as unsigned int.\n\nBefore:\n [root@fedora ~]# ss -f netlink\n Recv-Q Send-Q Local Address:Port Peer Address:Port\n -1668710080 0 rtnl:nl_wraparound/293 *\n\nAfter:\n [root@fedora ~]# ss -f netlink\n Recv-Q Send-Q Local Address:Port Peer Address:Port\n 2147483072 0 rtnl:nl_wraparound/290 *\n ^\n `--- INT_MAX - 576",
"id": "GHSA-q8rf-2mp5-5994",
"modified": "2026-05-12T15:30:58Z",
"published": "2025-07-25T18:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38465"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b8e18af7bea92f8b7fb92d40aeae729209db250"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55baecb9eb90238f60a8350660d6762046ebd3bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76602d8e13864524382b0687dc32cd8f19164d5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9da025150b7c14a8390fc06aea314c0a4011e82c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd7ff61bfffd7000143c42bbffb85eeb792466d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd69af06101090eaa60b3d216ae715f9c0a58e5b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-Q96W-JFJR-XWW5
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-08 15:31In the Linux kernel, the following vulnerability has been resolved:
devlink: Release nested relation on devlink free
devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached.
That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked.
Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.
{
"affected": [],
"aliases": [
"CVE-2026-53261"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndevlink: Release nested relation on devlink free\n\ndevlink relation state is normally released from devl_unregister(), which\ncalls devlink_rel_put(). This misses devlink instances that get a nested\nrelation before registration and then fail probe before devl_register() is\nreached.\n\nThat flow can happen for SFs. The child devlink gets linked to its\nparent before registration, then a later probe error calls devlink_free()\ndirectly. Since the instance was never registered, devl_unregister() is not\ncalled and devlink-\u003erel is leaked.\n\nRelease any pending relation from devlink_free() as well. The registered\npath is unchanged because devl_unregister() already clears devlink-\u003erel\nbefore devlink_free() runs.",
"id": "GHSA-q96w-jfjr-xww5",
"modified": "2026-07-08T15:31:48Z",
"published": "2026-06-25T09:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53261"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11324d52b0c63f4f202b35793c6507a575e9a689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3522b21fd7e1863d0734537737bd59f1b90d0190"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/927f96861f939c0b517d13ed27bf4fabbfc1cfb3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9137286884703113b1c9e6403bd6d7d97b14754"
}
],
"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-Q99F-WHJQ-3RRX
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
tun: Fix memory leak for detached NAPI queue.
syzkaller reported [0] memory leaks of sk and skb related to the TUN device with no repro, but we can reproduce it easily with:
struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {};
fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr);
ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr);
fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr);
write(fd_tun, buf, sizeof(buf)); close(fd_tun);
If we enable NAPI and multi-queue on a TUN device, we can put skb into tfile->sk.sk_write_queue after the queue is detached. We should prevent it by checking tfile->detached before queuing skb.
Note this must be done under tfile->sk.sk_write_queue.lock because write() and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would be a small race window:
write() ioctl(IFF_DETACH_QUEUE)
- tun_get_user- __tun_detach
|- if (tfile->detached) |- tun_disable_queue
| -> false |- tfile->detached = tun
| - tun_queue_purge
|- spin_lock_bh(&queue->lock)- __skb_queue_tail(queue, skb)
Another solution is to call tun_queue_purge() when closing and reattaching the detached queue, but it could paper over another problems. Also, we do the same kind of test for IFF_NAPI_FRAGS.
[0]: unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
unreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [< ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53685"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntun: Fix memory leak for detached NAPI queue.\n\nsyzkaller reported [0] memory leaks of sk and skb related to the TUN\ndevice with no repro, but we can reproduce it easily with:\n\n struct ifreq ifr = {}\n int fd_tun, fd_tmp;\n char buf[4] = {};\n\n fd_tun = openat(AT_FDCWD, \"/dev/net/tun\", O_WRONLY, 0);\n ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE;\n ioctl(fd_tun, TUNSETIFF, \u0026ifr);\n\n ifr.ifr_flags = IFF_DETACH_QUEUE;\n ioctl(fd_tun, TUNSETQUEUE, \u0026ifr);\n\n fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0);\n ifr.ifr_flags = IFF_UP;\n ioctl(fd_tmp, SIOCSIFFLAGS, \u0026ifr);\n\n write(fd_tun, buf, sizeof(buf));\n close(fd_tun);\n\nIf we enable NAPI and multi-queue on a TUN device, we can put skb into\ntfile-\u003esk.sk_write_queue after the queue is detached. We should prevent\nit by checking tfile-\u003edetached before queuing skb.\n\nNote this must be done under tfile-\u003esk.sk_write_queue.lock because write()\nand ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would\nbe a small race window:\n\n write() ioctl(IFF_DETACH_QUEUE)\n `- tun_get_user `- __tun_detach\n |- if (tfile-\u003edetached) |- tun_disable_queue\n | `-\u003e false | `- tfile-\u003edetached = tun\n | `- tun_queue_purge\n |- spin_lock_bh(\u0026queue-\u003elock)\n `- __skb_queue_tail(queue, skb)\n\nAnother solution is to call tun_queue_purge() when closing and\nreattaching the detached queue, but it could paper over another\nproblems. Also, we do the same kind of test for IFF_NAPI_FRAGS.\n\n[0]:\nunreferenced object 0xffff88801edbc800 (size 2048):\n comm \"syz-executor.1\", pid 33269, jiffies 4295743834 (age 18.756s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............\n backtrace:\n [\u003c000000008c16ea3d\u003e] __do_kmalloc_node mm/slab_common.c:965 [inline]\n [\u003c000000008c16ea3d\u003e] __kmalloc+0x4a/0x130 mm/slab_common.c:979\n [\u003c000000003addde56\u003e] kmalloc include/linux/slab.h:563 [inline]\n [\u003c000000003addde56\u003e] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035\n [\u003c000000003e20621f\u003e] sk_alloc+0x36/0x2f0 net/core/sock.c:2088\n [\u003c0000000028e43843\u003e] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438\n [\u003c000000001b0f1f28\u003e] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165\n [\u003c000000004376f706\u003e] chrdev_open+0x111/0x300 fs/char_dev.c:414\n [\u003c00000000614d379f\u003e] do_dentry_open+0x2f9/0x750 fs/open.c:920\n [\u003c000000008eb24774\u003e] do_open fs/namei.c:3636 [inline]\n [\u003c000000008eb24774\u003e] path_openat+0x143f/0x1a30 fs/namei.c:3791\n [\u003c00000000955077b5\u003e] do_filp_open+0xce/0x1c0 fs/namei.c:3818\n [\u003c00000000b78973b0\u003e] do_sys_openat2+0xf0/0x260 fs/open.c:1356\n [\u003c00000000057be699\u003e] do_sys_open fs/open.c:1372 [inline]\n [\u003c00000000057be699\u003e] __do_sys_openat fs/open.c:1388 [inline]\n [\u003c00000000057be699\u003e] __se_sys_openat fs/open.c:1383 [inline]\n [\u003c00000000057be699\u003e] __x64_sys_openat+0x83/0xf0 fs/open.c:1383\n [\u003c00000000a7d2182d\u003e] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [\u003c00000000a7d2182d\u003e] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80\n [\u003c000000004cc4e8c4\u003e] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nunreferenced object 0xffff88802f671700 (size 240):\n comm \"syz-executor.1\", pid 33269, jiffies 4295743854 (age 18.736s)\n hex dump (first 32 bytes):\n 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h.......\n 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............\n backtrace:\n [\u003c00000000e9d9fdb6\u003e] __alloc_skb+0x223/0x250 net/core/skbuff.c:644\n [\u003c000000002c3e4e0b\u003e] alloc_skb include/linux/skbuff.h:1288 [inline]\n [\u003c000000002c3e4e0b\u003e] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378\n [\u003c00000000825f98d7\u003e] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729\n [\u003c00000000e9eb3df3\u003e] tun_alloc_skb drivers/net/tun.c:1529 [inline]\n [\u003c\n---truncated---",
"id": "GHSA-q99f-whjq-3rrx",
"modified": "2026-02-03T18:30:30Z",
"published": "2025-10-07T18:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53685"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d20210a190f76db9ec35ee4e0fc77e6c7a148f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82b2bc279467c875ec36f8ef820f00997c2a4e8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9cae243b9ae25adfe468cd47ceca591f6725b79c"
}
],
"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-QC77-C9GC-J3X6
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-23 15:31In the Linux kernel, the following vulnerability has been resolved:
ethernet: Fix error handling in xemaclite_of_probe
This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. As the remove function do.
{
"affected": [],
"aliases": [
"CVE-2022-48860"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nethernet: Fix error handling in xemaclite_of_probe\n\nThis node pointer is returned by of_parse_phandle() with refcount\nincremented in this function. Calling of_node_put() to avoid the\nrefcount leak. As the remove function do.",
"id": "GHSA-qc77-c9gc-j3x6",
"modified": "2024-07-23T15:31:08Z",
"published": "2024-07-16T15:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48860"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1852854ee349881efb78ccdbbb237838975902e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8609e29611befc4bfbe7a91bb50fc65ae72ff549"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ee065a7a9b6a3976c16340503677efc4d8351f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/979b418b96e35f07136f77962ccfaa54cf3e30e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b19ab4b38b06aae12442b2de95ccf58b5dc53584"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7220f8e9d6c6b9594ddfb3125dad938cd478b1f"
}
],
"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-QCQG-8C98-934H
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-10 21:31In the Linux kernel, the following vulnerability has been resolved:
EDAC/versalnet: Fix device name memory leak
The device name allocated via kzalloc() in init_one_mc() is assigned to dev->init_name but never freed on the normal removal path. device_register() copies init_name and then sets dev->init_name to NULL, so the name pointer becomes unreachable from the device. Thus leaking memory.
Use a stack-local char array instead of using kzalloc() for name.
{
"affected": [],
"aliases": [
"CVE-2026-46221"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/versalnet: Fix device name memory leak\n\nThe device name allocated via kzalloc() in init_one_mc() is assigned to\ndev-\u003einit_name but never freed on the normal removal path. device_register()\ncopies init_name and then sets dev-\u003einit_name to NULL, so the name pointer\nbecomes unreachable from the device. Thus leaking memory.\n\nUse a stack-local char array instead of using kzalloc() for name.",
"id": "GHSA-qcqg-8c98-934h",
"modified": "2026-06-10T21:31:25Z",
"published": "2026-05-28T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46221"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24d2912962d087ebff7c4984f8ac34a5f23c8dbf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cf5dd235eff6008cb04c3d8064d2acfa90616f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b16033c8774f5fb4c0cb9b445a1dfc68f499ae6a"
}
],
"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-QCVW-PG56-GHF2
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-11-07 19:00Two memory leaks in the mwifiex_pcie_init_evt_ring() function in drivers/net/wireless/marvell/mwifiex/pcie.c in the Linux kernel through 5.3.11 allow attackers to cause a denial of service (memory consumption) by triggering mwifiex_map_pci_memory() failures, aka CID-d10dcb615c8e.
{
"affected": [],
"aliases": [
"CVE-2019-19057"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-18T06:15:00Z",
"severity": "HIGH"
},
"details": "Two memory leaks in the mwifiex_pcie_init_evt_ring() function in drivers/net/wireless/marvell/mwifiex/pcie.c in the Linux kernel through 5.3.11 allow attackers to cause a denial of service (memory consumption) by triggering mwifiex_map_pci_memory() failures, aka CID-d10dcb615c8e.",
"id": "GHSA-qcvw-pg56-ghf2",
"modified": "2022-11-07T19:00:20Z",
"published": "2022-05-24T17:01:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19057"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/d10dcb615c8e29d403a24d35f8310a7a53e3050c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/01/msg00013.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/O3PSDE6PTOTVBK2YTKB2TFQP2SUBVSNF"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PY7LJMSPAGRIKABJPDKQDTXYW3L5RX2T"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2020/Jan/10"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191205-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4254-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4254-2"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4284-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4285-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4287-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4287-2"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00029.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/155890/Slackware-Security-Advisory-Slackware-14.2-kernel-Updates.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:L",
"type": "CVSS_V3"
}
]
}
GHSA-QF5G-M559-VX7X
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03A memory leak vulnerability was found in Privoxy before 3.0.29 in the show-status CGI handler when no action files are configured.
{
"affected": [],
"aliases": [
"CVE-2021-20209"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-25T20:15:00Z",
"severity": "HIGH"
},
"details": "A memory leak vulnerability was found in Privoxy before 3.0.29 in the show-status CGI handler when no action files are configured.",
"id": "GHSA-qf5g-m559-vx7x",
"modified": "2022-05-24T19:03:09Z",
"published": "2022-05-24T19:03:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20209"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1928726"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-16"
},
{
"type": "WEB",
"url": "https://www.privoxy.org/3.0.29/user-manual/whatsnew.html"
},
{
"type": "WEB",
"url": "https://www.privoxy.org/gitweb/?p=privoxy.git;a=commit;h=c62254a686"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-QFGR-F5J7-2XXF
Vulnerability from github – Published: 2023-10-04 21:30 – Updated: 2024-03-11 15:31A memory leak flaw was found in Libtiff's tiffcrop utility. This issue occurs when tiffcrop operates on a TIFF image file, allowing an attacker to pass a crafted TIFF image file to tiffcrop utility, which causes this memory leak issue, resulting an application crash, eventually leading to a denial of service.
{
"affected": [],
"aliases": [
"CVE-2023-3576"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-04T19:15:10Z",
"severity": "MODERATE"
},
"details": "A memory leak flaw was found in Libtiff\u0027s tiffcrop utility. This issue occurs when tiffcrop operates on a TIFF image file, allowing an attacker to pass a crafted TIFF image file to tiffcrop utility, which causes this memory leak issue, resulting an application crash, eventually leading to a denial of service.",
"id": "GHSA-qfgr-f5j7-2xxf",
"modified": "2024-03-11T15:31:23Z",
"published": "2023-10-04T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3576"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:6575"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-3576"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2219340"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/03/msg00011.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QFJ5-Q5G9-M5PM
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-24 21:31In the Linux kernel, the following vulnerability has been resolved:
sctp: fix memory leak in sctp_stream_outq_migrate()
When sctp_stream_outq_migrate() is called to release stream out resources, the memory pointed to by prio_head in stream out is not released.
The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [] kmalloc_trace+0x26/0x60 [] sctp_sched_prio_set+0x4cc/0x770 [] sctp_stream_init_ext+0xd2/0x1b0 [] sctp_sendmsg_to_asoc+0x1614/0x1a30 [] sctp_sendmsg+0xda1/0x1ef0 [] inet_sendmsg+0x9d/0xe0 [] sock_sendmsg+0xd3/0x120 [] __sys_sendto+0x23a/0x340 [] __x64_sys_sendto+0xe1/0x1b0 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
{
"affected": [],
"aliases": [
"CVE-2022-49013"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix memory leak in sctp_stream_outq_migrate()\n\nWhen sctp_stream_outq_migrate() is called to release stream out resources,\nthe memory pointed to by prio_head in stream out is not released.\n\nThe memory leak information is as follows:\n unreferenced object 0xffff88801fe79f80 (size 64):\n comm \"sctp_repo\", pid 7957, jiffies 4294951704 (age 36.480s)\n hex dump (first 32 bytes):\n 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................\n 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................\n backtrace:\n [\u003cffffffff81b215c6\u003e] kmalloc_trace+0x26/0x60\n [\u003cffffffff88ae517c\u003e] sctp_sched_prio_set+0x4cc/0x770\n [\u003cffffffff88ad64f2\u003e] sctp_stream_init_ext+0xd2/0x1b0\n [\u003cffffffff88aa2604\u003e] sctp_sendmsg_to_asoc+0x1614/0x1a30\n [\u003cffffffff88ab7ff1\u003e] sctp_sendmsg+0xda1/0x1ef0\n [\u003cffffffff87f765ed\u003e] inet_sendmsg+0x9d/0xe0\n [\u003cffffffff8754b5b3\u003e] sock_sendmsg+0xd3/0x120\n [\u003cffffffff8755446a\u003e] __sys_sendto+0x23a/0x340\n [\u003cffffffff87554651\u003e] __x64_sys_sendto+0xe1/0x1b0\n [\u003cffffffff89978b49\u003e] do_syscall_64+0x39/0xb0\n [\u003cffffffff89a0008b\u003e] entry_SYSCALL_64_after_hwframe+0x63/0xcd",
"id": "GHSA-qfj5-q5g9-m5pm",
"modified": "2024-10-24T21:31:02Z",
"published": "2024-10-21T21:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49013"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0dfb9a566327182387c90100ea54d8426cee8c67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/176ee6c673ccd118e9392fd2dbb165423bdb99ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ed7bfc79542119ac0a9e1ce8a2a5285e43433e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7555681e50bdebed2c40ff7404ee73c2e932993"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa20f88271259d42ebe66f0a8c4c20199e888c99"
}
],
"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-QFJR-VF3F-5F8G
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-11 15:32In the Linux kernel, the following vulnerability has been resolved:
soc: ti: k3-socinfo: Fix regmap leak on probe failure
The mmio regmap allocated during probe is never freed.
Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.
{
"affected": [],
"aliases": [
"CVE-2026-43242"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: ti: k3-socinfo: Fix regmap leak on probe failure\n\nThe mmio regmap allocated during probe is never freed.\n\nSwitch to using the device managed allocator so that the regmap is\nreleased on probe failures (e.g. probe deferral) and on driver unbind.",
"id": "GHSA-qfjr-vf3f-5f8g",
"modified": "2026-05-11T15:32:08Z",
"published": "2026-05-06T12:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43242"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/458136527fe127fd051c1c9537f4540849780d70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab1ac24c407e4df326d7154a4deadd444e9209d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1006b5892ec8a95d039a89b47e6fd69cf607405"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbaa9e615608c204d384a7d4b1a434580a142d4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c933138d45176780fabbbe7da263e04d5b3e525d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c97c21d342838b2a7787b0f1d6ad417e85c906f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d451bf970a0c54b586f8b3161261bdf35d463c99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eaa16059f9af26d8b8a6f3e887649f58e8ca96c9"
}
],
"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.