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-5W42-RMVH-MVW5
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
scsi: snic: Fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
{
"affected": [],
"aliases": [
"CVE-2023-53414"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: snic: Fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic at\nonce.",
"id": "GHSA-5w42-rmvh-mvw5",
"modified": "2025-12-11T15:30:30Z",
"published": "2025-09-18T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53414"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3dec769caf337c55814fbf79ec8c91a3cce23bf3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a46d8bdaf03e8a4bb83f0c363326d9aa66cc122"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/995424f59ab52fb432b26ccb3abced63745ea041"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad0e4e2fab928477f74d742e6e77d79245d3d3e7"
}
],
"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-5W45-X7P5-4GFH
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.
{
"affected": [],
"aliases": [
"CVE-2022-49331"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling\n\nError paths do not free previously allocated memory. Add devm_kfree() to\nthose failure paths.",
"id": "GHSA-5w45-x7p5-4gfh",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49331"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3eca2c42daa4659965db6817479027cbc6df7899"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e"
}
],
"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-5WF2-HXF9-8HXR
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-21 21:30In the Linux kernel, the following vulnerability has been resolved:
tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.
syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY skbs. We can reproduce the problem with these sequences:
sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close()
sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets skb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, struct ubuf_info_msgzc indirectly holds a refcnt of the socket. When the skb is sent, __skb_tstamp_tx() clones it and puts the clone into the socket's error queue with the TX timestamp.
When the original skb is received locally, skb_copy_ubufs() calls skb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt. This additional count is decremented while freeing the skb, but struct ubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is not called.
The last refcnt is not released unless we retrieve the TX timestamped skb by recvmsg(). Since we clear the error queue in inet_sock_destruct() after the socket's refcnt reaches 0, there is a circular dependency. If we close() the socket holding such skbs, we never call sock_put() and leak the count, sk, and skb.
TCP has the same problem, and commit e0c8bccd40fc ("net: stream: purge sk_error_queue in sk_stream_kill_queues()") tried to fix it by calling skb_queue_purge() during close(). However, there is a small chance that skb queued in a qdisc or device could be put into the error queue after the skb_queue_purge() call.
In __skb_tstamp_tx(), the cloned skb should not have a reference to the ubuf to remove the circular dependency, but skb_clone() does not call skb_copy_ubufs() for zerocopy skb. So, we need to call skb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().
[0]: BUG: memory leak unreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
BUG: memory leak unreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53489"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.\n\nsyzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY\nskbs. We can reproduce the problem with these sequences:\n\n sk = socket(AF_INET, SOCK_DGRAM, 0)\n sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE)\n sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1)\n sk.sendto(b\u0027\u0027, MSG_ZEROCOPY, (\u0027127.0.0.1\u0027, 53))\n sk.close()\n\nsendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets\nskb-\u003ecb-\u003eubuf.refcnt to 1, and calls sock_hold(). Here, struct\nubuf_info_msgzc indirectly holds a refcnt of the socket. When the\nskb is sent, __skb_tstamp_tx() clones it and puts the clone into\nthe socket\u0027s error queue with the TX timestamp.\n\nWhen the original skb is received locally, skb_copy_ubufs() calls\nskb_unclone(), and pskb_expand_head() increments skb-\u003ecb-\u003eubuf.refcnt.\nThis additional count is decremented while freeing the skb, but struct\nubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is\nnot called.\n\nThe last refcnt is not released unless we retrieve the TX timestamped\nskb by recvmsg(). Since we clear the error queue in inet_sock_destruct()\nafter the socket\u0027s refcnt reaches 0, there is a circular dependency.\nIf we close() the socket holding such skbs, we never call sock_put()\nand leak the count, sk, and skb.\n\nTCP has the same problem, and commit e0c8bccd40fc (\"net: stream:\npurge sk_error_queue in sk_stream_kill_queues()\") tried to fix it\nby calling skb_queue_purge() during close(). However, there is a\nsmall chance that skb queued in a qdisc or device could be put\ninto the error queue after the skb_queue_purge() call.\n\nIn __skb_tstamp_tx(), the cloned skb should not have a reference\nto the ubuf to remove the circular dependency, but skb_clone() does\nnot call skb_copy_ubufs() for zerocopy skb. So, we need to call\nskb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().\n\n[0]:\nBUG: memory leak\nunreferenced object 0xffff88800c6d2d00 (size 1152):\n comm \"syz-executor392\", pid 264, jiffies 4294785440 (age 13.044s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................\n 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............\n backtrace:\n [\u003c0000000055636812\u003e] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024\n [\u003c0000000054d77b7a\u003e] sk_alloc+0x3b/0x800 net/core/sock.c:2083\n [\u003c0000000066f3c7e0\u003e] inet_create net/ipv4/af_inet.c:319 [inline]\n [\u003c0000000066f3c7e0\u003e] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245\n [\u003c000000009b83af97\u003e] __sock_create+0x2ab/0x550 net/socket.c:1515\n [\u003c00000000b9b11231\u003e] sock_create net/socket.c:1566 [inline]\n [\u003c00000000b9b11231\u003e] __sys_socket_create net/socket.c:1603 [inline]\n [\u003c00000000b9b11231\u003e] __sys_socket_create net/socket.c:1588 [inline]\n [\u003c00000000b9b11231\u003e] __sys_socket+0x138/0x250 net/socket.c:1636\n [\u003c000000004fb45142\u003e] __do_sys_socket net/socket.c:1649 [inline]\n [\u003c000000004fb45142\u003e] __se_sys_socket net/socket.c:1647 [inline]\n [\u003c000000004fb45142\u003e] __x64_sys_socket+0x73/0xb0 net/socket.c:1647\n [\u003c0000000066999e0e\u003e] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [\u003c0000000066999e0e\u003e] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80\n [\u003c0000000017f238c1\u003e] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nBUG: memory leak\nunreferenced object 0xffff888017633a00 (size 240):\n comm \"syz-executor392\", pid 264, jiffies 4294785440 (age 13.044s)\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 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m.....\n backtrace:\n [\u003c000000002b1c4368\u003e] __alloc_skb+0x229/0x320 net/core/skbuff.c:497\n [\u003c00000000143579a6\u003e] alloc_skb include/linux/skbuff.h:1265 [inline]\n [\u003c00000000143579a6\u003e] sock_omalloc+0xaa/0x190 net/core/sock.c:2596\n [\u003c00000000be626478\u003e] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline]\n [\u003c00000000be626478\u003e]\n---truncated---",
"id": "GHSA-5wf2-hxf9-8hxr",
"modified": "2026-01-21T21:30:27Z",
"published": "2025-10-01T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53489"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f69c086b20e27763af28145981435423f088268"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/230a5ed7d813fb516de81d23f09d7506753e41e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/281072fb2a7294cde7acbf5375b879f40a8001b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30290f210ba7426ff7592fe2eb4114b1b5bad219"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/426384dd4980040651536fef5feac4dcc4d7ee4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43e4197dd5f6b474a8b16f8b6a42cd45cf4f9d1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50749f2dd6854a41830996ad302aef2ffaf011d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/602fa8af44fd55a58f9e94eb673e8adad2c6cc46"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb52e7f24c1d01a536a847dff0d1d95889cc3b5c"
}
],
"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-5WFX-MRW3-HHMX
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2023-01-18 00:30A memory leak in the ca8210_probe() function in drivers/net/ieee802154/ca8210.c in the Linux kernel before 5.3.8 allows attackers to cause a denial of service (memory consumption) by triggering ca8210_get_platform_data() failures, aka CID-6402939ec86e.
{
"affected": [],
"aliases": [
"CVE-2019-19075"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-18T06:15:00Z",
"severity": "HIGH"
},
"details": "A memory leak in the ca8210_probe() function in drivers/net/ieee802154/ca8210.c in the Linux kernel before 5.3.8 allows attackers to cause a denial of service (memory consumption) by triggering ca8210_get_platform_data() failures, aka CID-6402939ec86e.",
"id": "GHSA-5wfx-mrw3-hhmx",
"modified": "2023-01-18T00:30:25Z",
"published": "2022-05-24T17:01:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19075"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/6402939ec86eaf226c8b8ae00ed983936b164908"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.3.8"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191205-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4208-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4210-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4226-1"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00029.html"
}
],
"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-5WHM-XP9M-869G
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-23 03:30In the Linux kernel, the following vulnerability has been resolved:
clk: tegra: tegra124-emc: Fix potential memory leak
The tegra and tegra needs to be freed in the error handling path, otherwise it will be leaked.
{
"affected": [],
"aliases": [
"CVE-2023-53505"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: tegra: tegra124-emc: Fix potential memory leak\n\nThe tegra and tegra needs to be freed in the error handling path, otherwise\nit will be leaked.",
"id": "GHSA-5whm-xp9m-869g",
"modified": "2026-01-23T03:30:29Z",
"published": "2025-10-01T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53505"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/404e9f741acfb188212f7142d91e247630dd77cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e59e355f9fcccd9edf65d09f769bb4c163a1c36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53a06e5924c0d43c11379a08c5a78529c3e61595"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/801c8341f7aff07c494b53e627970b72635af5d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96bafece6ff380138896f009141fd7337070e680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e969c144d908ea9387442659f103d374c8ff682d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd1c117bb5d7e033bf1aa25ac97ff421f81a1199"
}
],
"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-5WP9-X843-XMXF
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-07 18:30In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_fib: fix stale stack leak via the OIFNAME register
For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.
The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale.
Fix both:
-
replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and
-
restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
{
"affected": [],
"aliases": [
"CVE-2026-53134"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_fib: fix stale stack leak via the OIFNAME register\n\nFor NFT_FIB_RESULT_OIFNAME the destination register is declared with\nlen = IFNAMSIZ (four 32-bit registers), but on the lookup-fail,\nRTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one\nregister via \"*dest = 0\". The remaining three registers are left as\nwhatever was on the stack in nft_do_chain()\u0027s struct nft_regs, and a\ndownstream expression that loads the register span can leak that\nuninitialised kernel stack to userspace.\n\nThe NFTA_FIB_F_PRESENT existence check has the same shape: it is only\nmeaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type\nwhile the eval stores a single byte via nft_reg_store8(), leaving the rest\nof the declared span stale.\n\nFix both:\n\n - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(),\n which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already\n used on the other early-return path), and\n\n - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its\n destination as a single u8, so the marked span matches the one byte\n the eval writes.",
"id": "GHSA-5wp9-x843-xmxf",
"modified": "2026-07-07T18:30:27Z",
"published": "2026-06-25T09:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53134"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3544210609f6d1db282bbdeca639104ef624c393"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6744e49fe51bfba26522acc2d0e9703cb41d8e50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84d8f58cf28a0415413f43ba7148f7bacd4c1b6e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c84885e9790823828bb8084736ea15769b1ac16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab185e0c4fb82dfba6fb86f8271e06f931d9c64c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d19ddef8c327a4773ff81f8e51027d1e0b4cf069"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb8a8124484dbc3c2b543e207da39bbccb703d31"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eca18feed38b3377a2ec5d1f22af1170c55d0171"
}
],
"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-5WX2-VV79-WFG8
Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-12-11 18:30In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory leak when build ntlmssp negotiate blob failed
There is a memory leak when mount cifs: unreferenced object 0xffff888166059600 (size 448): comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s) hex dump (first 32 bytes): fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000060609a61>] mempool_alloc+0xe1/0x260 [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60 [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460 [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0 [<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480 [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410 [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0 [<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0 [<000000006cbc43d9>] mount_get_conns+0x7a/0x730 [<000000005922d816>] cifs_mount+0x103/0xd10 [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90 [<0000000078034979>] smb3_get_tree+0x1d5/0x300 [<000000004371f980>] vfs_get_tree+0x41/0xf0 [<00000000b670d8a7>] path_mount+0x9b3/0xdd0 [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0 [<000000009404c3b9>] do_syscall_64+0x35/0x80
When build ntlmssp negotiate blob failed, the session setup request should be freed.
{
"affected": [],
"aliases": [
"CVE-2022-50372"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-17T15:15:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory leak when build ntlmssp negotiate blob failed\n\nThere is a memory leak when mount cifs:\n unreferenced object 0xffff888166059600 (size 448):\n comm \"mount.cifs\", pid 51391, jiffies 4295596373 (age 330.596s)\n hex dump (first 32 bytes):\n fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@...........\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u003c0000000060609a61\u003e] mempool_alloc+0xe1/0x260\n [\u003c00000000adfa6c63\u003e] cifs_small_buf_get+0x24/0x60\n [\u003c00000000ebb404c7\u003e] __smb2_plain_req_init+0x32/0x460\n [\u003c00000000bcf875b4\u003e] SMB2_sess_alloc_buffer+0xa4/0x3f0\n [\u003c00000000753a2987\u003e] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480\n [\u003c00000000f0c1f4f9\u003e] SMB2_sess_setup+0x253/0x410\n [\u003c00000000a8b83303\u003e] cifs_setup_session+0x18f/0x4c0\n [\u003c00000000854bd16d\u003e] cifs_get_smb_ses+0xae7/0x13c0\n [\u003c000000006cbc43d9\u003e] mount_get_conns+0x7a/0x730\n [\u003c000000005922d816\u003e] cifs_mount+0x103/0xd10\n [\u003c00000000e33def3b\u003e] cifs_smb3_do_mount+0x1dd/0xc90\n [\u003c0000000078034979\u003e] smb3_get_tree+0x1d5/0x300\n [\u003c000000004371f980\u003e] vfs_get_tree+0x41/0xf0\n [\u003c00000000b670d8a7\u003e] path_mount+0x9b3/0xdd0\n [\u003c000000005e839a7d\u003e] __x64_sys_mount+0x190/0x1d0\n [\u003c000000009404c3b9\u003e] do_syscall_64+0x35/0x80\n\nWhen build ntlmssp negotiate blob failed, the session setup request\nshould be freed.",
"id": "GHSA-5wx2-vv79-wfg8",
"modified": "2025-12-11T18:30:31Z",
"published": "2025-09-17T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50372"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30b2d7f8f13664655480d6af45f60270b3eb6736"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa5a70bdd5e565c8696fb04dfe18a4e8aff4695d"
}
],
"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-5X4F-4RC3-FXCX
Vulnerability from github – Published: 2026-02-02 18:31 – Updated: 2026-02-02 18:31Memory Corruption when initiating GPU memory mapping using scatter-gather lists due to unchecked IOMMU mapping errors.
{
"affected": [],
"aliases": [
"CVE-2025-47397"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-02T16:16:19Z",
"severity": "HIGH"
},
"details": "Memory Corruption when initiating GPU memory mapping using scatter-gather lists due to unchecked IOMMU mapping errors.",
"id": "GHSA-5x4f-4rc3-fxcx",
"modified": "2026-02-02T18:31:32Z",
"published": "2026-02-02T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47397"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/february-2026-bulletin.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5X7Q-6F7M-FC5C
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36An issue was discovered in Xen 4.6 through 4.14.x. When acting upon a guest XS_RESET_WATCHES request, not all tracking information is freed. A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS. Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable.
{
"affected": [],
"aliases": [
"CVE-2020-29485"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-15T18:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Xen 4.6 through 4.14.x. When acting upon a guest XS_RESET_WATCHES request, not all tracking information is freed. A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS. Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable.",
"id": "GHSA-5x7q-6f7m-fc5c",
"modified": "2022-05-24T17:36:33Z",
"published": "2022-05-24T17:36:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29485"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4812"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-330.txt"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5XGR-QHGC-XHWH
Vulnerability from github – Published: 2022-05-13 01:13 – Updated: 2025-04-20 03:39Memory leak in QEMU (aka Quick Emulator), when built with USB EHCI Emulation support, allows local guest OS privileged users to cause a denial of service (memory consumption) by repeatedly hot-unplugging the device.
{
"affected": [],
"aliases": [
"CVE-2017-9374"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-16T22:29:00Z",
"severity": "MODERATE"
},
"details": "Memory leak in QEMU (aka Quick Emulator), when built with USB EHCI Emulation support, allows local guest OS privileged users to cause a denial of service (memory consumption) by repeatedly hot-unplugging the device.",
"id": "GHSA-5xgr-qhgc-xhwh",
"modified": "2025-04-20T03:39:19Z",
"published": "2022-05-13T01:13:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9374"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2392"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2408"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1459132"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00007.html"
},
{
"type": "WEB",
"url": "http://git.qemu.org/?p=qemu.git%3Ba=commit%3Bh=d710e1e7bd3d5bfc26b631f02ae87901ebe646b0"
},
{
"type": "WEB",
"url": "http://git.qemu.org/?p=qemu.git;a=commit;h=d710e1e7bd3d5bfc26b631f02ae87901ebe646b0"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3920"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2017/06/06/3"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98905"
}
],
"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.