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.
2291 vulnerabilities reference this CWE, most recent first.
GHSA-MMCW-F5QH-65Q3
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2025-04-02 15:30In the Linux kernel, the following vulnerability has been resolved:
net/handshake: Fix handshake_req_destroy_test1
Recently, handshake_req_destroy_test1 started failing:
Expected handshake_req_destroy_test == req, but handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 not ok 11 req_destroy works
This is because "sock_release(sock)" was replaced with "fput(filp)" to address a memory leak. Note that sock_release() is synchronous but fput() usually delays the final close and clean-up.
The delay is not consequential in the other cases that were changed but handshake_req_destroy_test1 is testing that handshake_req_cancel() followed by closing the file actually does call the ->hp_destroy method. Thus the PTR_EQ test at the end has to be sure that the final close is complete before it checks the pointer.
We cannot use a completion here because if ->hp_destroy is never called (ie, there is an API bug) then the test will hang.
Reported by: Guenter Roeck linux@roeck-us.net
{
"affected": [],
"aliases": [
"CVE-2024-26831"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T10:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/handshake: Fix handshake_req_destroy_test1\n\nRecently, handshake_req_destroy_test1 started failing:\n\nExpected handshake_req_destroy_test == req, but\n handshake_req_destroy_test == 0000000000000000\n req == 0000000060f99b40\nnot ok 11 req_destroy works\n\nThis is because \"sock_release(sock)\" was replaced with \"fput(filp)\"\nto address a memory leak. Note that sock_release() is synchronous\nbut fput() usually delays the final close and clean-up.\n\nThe delay is not consequential in the other cases that were changed\nbut handshake_req_destroy_test1 is testing that handshake_req_cancel()\nfollowed by closing the file actually does call the -\u003ehp_destroy\nmethod. Thus the PTR_EQ test at the end has to be sure that the\nfinal close is complete before it checks the pointer.\n\nWe cannot use a completion here because if -\u003ehp_destroy is never\ncalled (ie, there is an API bug) then the test will hang.\n\nReported by: Guenter Roeck \u003clinux@roeck-us.net\u003e",
"id": "GHSA-mmcw-f5qh-65q3",
"modified": "2025-04-02T15:30:50Z",
"published": "2024-04-17T12:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26831"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e1d71cabb19ec2586827adfc60d68689c68c194"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f97805b8df6e33850e225e6bd3ebd9e246920af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d74226e03df1bf19848f18344401f254345af912"
}
],
"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-MMVG-F8X9-HVR5
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-24 15:32In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: bind uarg before filling zerocopy skb
virtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg before entering the send loop, but virtio_transport_alloc_skb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfree_skb() to free an skb that carries SKBFL_MANAGED_FRAG_REFS but no uarg, so skb_release_data() falls through to ordinary frag unref.
Pass the uarg into virtio_transport_alloc_skb() and bind it immediately before virtio_transport_fill_skb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule.
{
"affected": [],
"aliases": [
"CVE-2026-63970"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:16Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: bind uarg before filling zerocopy skb\n\nvirtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg\nbefore entering the send loop, but virtio_transport_alloc_skb() still\nfills the skb before it inherits that uarg. When fixed-buffer vectored\nzerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach\nmanaged frags and return -EMSGSIZE. The rollback path call kfree_skb()\nto free an skb that carries SKBFL_MANAGED_FRAG_REFS but no uarg, so\nskb_release_data() falls through to ordinary frag unref.\n\nPass the uarg into virtio_transport_alloc_skb() and bind it immediately\nbefore virtio_transport_fill_skb(). This keeps control or no-payload skbs\nuntouched while ensuring success and rollback share one lifetime rule.",
"id": "GHSA-mmvg-f8x9-hvr5",
"modified": "2026-07-24T15:32:43Z",
"published": "2026-07-19T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63970"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e584c304cfb94a759417130b1fc6d30b30c4cce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d317573f1d48e76cce5fb6250452b6e4102e0fb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72194f65050958e4c8e069adb6c5d89ef81ca197"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b62e2b2b4a50953ca952f3cd3f77dd62dc50fd5d"
}
],
"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-MMVQ-WVQC-3Q85
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-07 21:30In the Linux kernel, the following vulnerability has been resolved:
comedi: runflags cannot determine whether to reclaim chanlist
syzbot reported a memory leak [1], because commit 4e1da516debb ("comedi: Add reference counting for Comedi command handling") did not consider the exceptional exit case in do_cmd_ioctl() where runflags is not set. This caused chanlist not to be properly freed by do_become_nonbusy(), as it only frees chanlist when runflags is correctly set.
Added a check in do_become_nonbusy() for the case where runflags is not set, to properly free the chanlist memory.
[1] BUG: memory leak backtrace (crc 844a0efa): __comedi_get_user_chanlist drivers/comedi/comedi_fops.c:1815 [inline] do_cmd_ioctl.part.0+0x112/0x350 drivers/comedi/comedi_fops.c:1890 do_cmd_ioctl drivers/comedi/comedi_fops.c:1858 [inline]
{
"affected": [],
"aliases": [
"CVE-2026-31750"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: runflags cannot determine whether to reclaim chanlist\n\nsyzbot reported a memory leak [1], because commit 4e1da516debb (\"comedi:\nAdd reference counting for Comedi command handling\") did not consider\nthe exceptional exit case in do_cmd_ioctl() where runflags is not set.\nThis caused chanlist not to be properly freed by do_become_nonbusy(),\nas it only frees chanlist when runflags is correctly set.\n\nAdded a check in do_become_nonbusy() for the case where runflags is not\nset, to properly free the chanlist memory.\n\n[1]\nBUG: memory leak\n backtrace (crc 844a0efa):\n __comedi_get_user_chanlist drivers/comedi/comedi_fops.c:1815 [inline]\n do_cmd_ioctl.part.0+0x112/0x350 drivers/comedi/comedi_fops.c:1890\n do_cmd_ioctl drivers/comedi/comedi_fops.c:1858 [inline]",
"id": "GHSA-mmvq-wvqc-3q85",
"modified": "2026-05-07T21:30:23Z",
"published": "2026-05-01T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31750"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29f644f14b89e6c4965e3c89251929e451190a66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/830c848aba9f047eb6b34288975ebeb8e8621451"
}
],
"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-MP6X-J3PP-4P34
Vulnerability from github – Published: 2025-05-02 18:31 – Updated: 2025-11-12 21:31In the Linux kernel, the following vulnerability has been resolved:
interconnect: exynos: fix node leak in probe PM QoS error path
Make sure to add the newly allocated interconnect node to the provider before adding the PM QoS request so that the node is freed on errors.
{
"affected": [],
"aliases": [
"CVE-2023-53092"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-02T16:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: exynos: fix node leak in probe PM QoS error path\n\nMake sure to add the newly allocated interconnect node to the provider\nbefore adding the PM QoS request so that the node is freed on errors.",
"id": "GHSA-mp6x-j3pp-4p34",
"modified": "2025-11-12T21:31:01Z",
"published": "2025-05-02T18:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53092"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3aab264875bf3c915ea2517fae1eec213e0b4987"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b71dd43bd49bd68186c1d19dbeedee219e003149"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c479e4ac4a3d1485a48599e66ce46547c1367828"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd4738ae1a0c216d25360a98e835967b06d6a253"
}
],
"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-MP79-8QQ6-QP9G
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-10-15 03:36In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix possible kfree_skb of ERR_PTR
After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex.
However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking.
If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer.
Fix this by setting the pointer to NULL after having saved its error value.
{
"affected": [],
"aliases": [
"CVE-2026-53227"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix possible kfree_skb of ERR_PTR\n\nAfter the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb\ncan happen either before or after locking the ovs_mutex.\n\nHowever, error cleanups still follow the classical reversed order,\nassuming \"reply\" is allocated before locking: it is freed after unlocking.\n\nIf \"reply\" allocation happens after locking the mutex and it fails,\n\"reply\" is left with an ERR_PTR, and execution jumps to the correspondent\ncleanup stage which will try to free an invalid pointer.\n\nFix this by setting the pointer to NULL after having saved its error\nvalue.",
"id": "GHSA-mp79-8qq6-qp9g",
"modified": "2026-10-15T03:36:16Z",
"published": "2026-06-25T09:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53227"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bb5b2dc1b90aa7dd1473fc8c4d813a29255ff8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25fdf53698535fe8790237f5a8a9626791429785"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/895d1dd9057cde1687fa0f4286d47ceed0b82997"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/971b1b37774f13acc5add0a2843f8598446b8598"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e248fb2e680deb2bd37bac551b72638fe4938a76"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3d509a1b71396e1452060dbf84a805fd1c3c549"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecc55aad3390129a87106841f4b68bf3d70c9264"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee30dd2909d8b98619f4341c70ec8dc8e155ab02"
}
],
"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-MP8M-M46Q-CQX4
Vulnerability from github – Published: 2026-01-23 15:31 – Updated: 2026-02-26 21:31In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory and information leak in smb3_reconfigure()
In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak.
Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.
{
"affected": [],
"aliases": [
"CVE-2025-71151"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-23T15:16:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory and information leak in smb3_reconfigure()\n\nIn smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the\nfunction returns immediately without freeing and erasing the newly\nallocated new_password and new_password2. This causes both a memory leak\nand a potential information leak.\n\nFix this by calling kfree_sensitive() on both password buffers before\nreturning in this error case.",
"id": "GHSA-mp8m-m46q-cqx4",
"modified": "2026-02-26T21:31:26Z",
"published": "2026-01-23T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71151"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5679cc90bb5415801fa29041da0319d9e15d295d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb82aaee16907dc4d0b9b0ca7953ceb3edc328c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc390b2737205163e48cc1655f6a0c8cd55b02fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb6d5aa9c0f10074f1ad056c3e2278ad2cc7ec8d"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-MP8V-432G-7V26
Vulnerability from github – Published: 2024-11-09 12:30 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address
The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver.
Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it.
Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it.
[1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0
[2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
[3] unreferenced object 0xffff898081f597a0 (size 32): comm "ip", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0
{
"affected": [],
"aliases": [
"CVE-2024-50252"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T11:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address\n\nThe device stores IPv6 addresses that are used for encapsulation in\nlinear memory that is managed by the driver.\n\nChanging the remote address of an ip6gre net device never worked\nproperly, but since cited commit the following reproducer [1] would\nresult in a warning [2] and a memory leak [3]. The problem is that the\nnew remote address is never added by the driver to its hash table (and\ntherefore the device) and the old address is never removed from it.\n\nFix by programming the new address when the configuration of the ip6gre\nnet device changes and removing the old one. If the address did not\nchange, then the above would result in increasing the reference count of\nthe address and then decreasing it.\n\n[1]\n # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit\n # ip link set dev bla type ip6gre remote 2001:db8:3::1\n # ip link del dev bla\n # devlink dev reload pci/0000:01:00.0\n\n[2]\nWARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0\nModules linked in:\nCPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nRIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0\n[...]\nCall Trace:\n \u003cTASK\u003e\n mlxsw_sp_router_netdevice_event+0x55f/0x1240\n notifier_call_chain+0x5a/0xd0\n call_netdevice_notifiers_info+0x39/0x90\n unregister_netdevice_many_notify+0x63e/0x9d0\n rtnl_dellink+0x16b/0x3a0\n rtnetlink_rcv_msg+0x142/0x3f0\n netlink_rcv_skb+0x50/0x100\n netlink_unicast+0x242/0x390\n netlink_sendmsg+0x1de/0x420\n ____sys_sendmsg+0x2bd/0x320\n ___sys_sendmsg+0x9a/0xe0\n __sys_sendmsg+0x7a/0xd0\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[3]\nunreferenced object 0xffff898081f597a0 (size 32):\n comm \"ip\", pid 1626, jiffies 4294719324\n hex dump (first 32 bytes):\n 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ...............\n 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia.............\n backtrace (crc fd9be911):\n [\u003c00000000df89c55d\u003e] __kmalloc_cache_noprof+0x1da/0x260\n [\u003c00000000ff2a1ddb\u003e] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340\n [\u003c000000009ddd445d\u003e] mlxsw_sp_router_netdevice_event+0x47b/0x1240\n [\u003c00000000743e7757\u003e] notifier_call_chain+0x5a/0xd0\n [\u003c000000007c7b9e13\u003e] call_netdevice_notifiers_info+0x39/0x90\n [\u003c000000002509645d\u003e] register_netdevice+0x5f7/0x7a0\n [\u003c00000000c2e7d2a9\u003e] ip6gre_newlink_common.isra.0+0x65/0x130\n [\u003c0000000087cd6d8d\u003e] ip6gre_newlink+0x72/0x120\n [\u003c000000004df7c7cc\u003e] rtnl_newlink+0x471/0xa20\n [\u003c0000000057ed632a\u003e] rtnetlink_rcv_msg+0x142/0x3f0\n [\u003c0000000032e0d5b5\u003e] netlink_rcv_skb+0x50/0x100\n [\u003c00000000908bca63\u003e] netlink_unicast+0x242/0x390\n [\u003c00000000cdbe1c87\u003e] netlink_sendmsg+0x1de/0x420\n [\u003c0000000011db153e\u003e] ____sys_sendmsg+0x2bd/0x320\n [\u003c000000003b6d53eb\u003e] ___sys_sendmsg+0x9a/0xe0\n [\u003c00000000cae27c62\u003e] __sys_sendmsg+0x7a/0xd0",
"id": "GHSA-mp8v-432g-7v26",
"modified": "2025-11-04T00:32:00Z",
"published": "2024-11-09T12:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50252"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12ae97c531fcd3bfd774d4dfeaeac23eafe24280"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31384aa2ad05c29c7745000f321154f42de24d1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1bbdbe07f0bc3bc9f87efe4672d67208c6d6942"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8f298eb6659eb6a38e26b79e77de4449dc6e61b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MPC7-4W3V-V47R
Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix posix_acl leak on SETACL decode failure
nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling.
ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure:
svc_process_common()
pc_decode() /* decode_setaclargs: false */
/* pc_func skipped */
pc_release() /* fh_put only -- ACLs leaked */
The orphaned posix_acl is leaked for the lifetime of the server.
Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.
{
"affected": [],
"aliases": [
"CVE-2026-53397"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T12:16:50Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix posix_acl leak on SETACL decode failure\n\nnfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each\ncall nfs_stream_decode_acl() twice, first for NFS_ACL and then for\nNFS_DFACL. Each successful call transfers ownership of a freshly\nallocated posix_acl into argp-\u003eacl_access or argp-\u003eacl_default. If\nthe first call succeeds but the second fails, the decoder returns\nfalse and argp-\u003eacl_access is left dangling.\n\nACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and\nACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle.\nBoth only call fh_put() and have no knowledge of the ACL fields on\nargp. The posix_acl_release() pairs sat at the out: labels inside\nnfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process()\nskips pc_func when pc_decode returns false, so that cleanup is\nunreachable on decode failure:\n\n svc_process_common()\n pc_decode() /* decode_setaclargs: false */\n /* pc_func skipped */\n pc_release() /* fh_put only -- ACLs leaked */\n\nThe orphaned posix_acl is leaked for the lifetime of the server.\n\nFix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(),\nwhich release both argp-\u003eacl_access and argp-\u003eacl_default in addition\nto fh_put(), and wiring them as pc_release for their respective SETACL\nprocedures. pc_release runs on every path svc_process() takes after\ndecode, including decode failure, so the posix_acl_release() pairs are\nremoved from the proc functions\u0027 out: labels to keep ownership in one\nplace. This matches the existing release_getacl() pattern used by\nthe sibling GETACL procedures.",
"id": "GHSA-mpc7-4w3v-v47r",
"modified": "2026-07-20T15:31:45Z",
"published": "2026-07-19T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53397"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0853ac544c590880d797b04daa33fcb72b6be0e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/136b416593f1349cf6f72c8e3d18f0f204ee8545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e96239fddcefacf6afe6c498357be68eacbcabc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/887f92ceccf3eacd5f2402db21254d66372fae00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5b42c1e4ff2befaa6b96f7cbf32174751eba083"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2eb1ffd511d1b3c3e21122f97cbbccea411e277"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b94c4be77682aab06d65ca7296149e3bcfb37353"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd69a825485168ef74e815ecb286754b570fdcc7"
}
],
"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-MPQX-Q82W-9X46
Vulnerability from github – Published: 2026-10-30 22:58 – Updated: 2026-10-30 22:58Summary
When a validation was aborted because the document contained more errors than allowed by max_errors (100 by default), validate() raised a single module-level ValidationAbortedError instance. Python appends the frames of every raise to the existing __traceback__ of an exception that is raised again, so every aborted validation extended the traceback of this shared error. That traceback kept the frames, and with them the document, the validation context and all errors of every aborted validation, alive for the lifetime of the process.
Details
Any client can trigger an aborted validation by sending a small document with more than 100 validation errors, e.g. 101 unknown fields. No authentication is required, and since validation runs before execution, depth limiters and complexity analyzers do not prevent it. Each such request permanently retained about 124 KiB on CPython 3.12, without an upper limit, so memory grew with every request until the process was restarted or killed.
GraphQL.js uses a shared error object at the same place, but JavaScript errors capture their stack trace only once when they are created, so it is not affected. GraphQL-core 3.2 creates a new error for each aborted validation and is not affected either.
Proof of concept
import gc
import tracemalloc
from graphql import build_schema, parse, validate
schema = build_schema("type Query { a: Int }")
document = parse("{ " + " ".join(f"f{i}" for i in range(101)) + " }")
tracemalloc.start()
validate(schema, document)
gc.collect()
base = tracemalloc.get_traced_memory()[0]
for _ in range(200):
validate(schema, document)
gc.collect()
print((tracemalloc.get_traced_memory()[0] - base) // 1024, "KiB")
With GraphQL-core 3.3.0 on CPython 3.12, the retained memory grows from 147 KiB after one call to about 25 MB after 200 calls. With the fix, it stays constant at about 180 KiB.
Impact
Denial of service through memory exhaustion. A few thousand small requests are enough to push a worker past a typical 256 MB or 512 MB container limit and trigger an OOM kill. No data is disclosed or modified.
Patches
Fixed in 3.3.1.
validate() now creates a new ValidationAbortedError for every aborted validation and removes its traceback and exception context before returning it, so that the returned errors do not keep the frames of the validation alive. The module-level validation_aborted_error instance, which was not exported, has been removed.
Workarounds
If you cannot upgrade, clear the traceback of the shared error after each validation:
from graphql.validation import validate as validate_document
from graphql.validation.validate import validation_aborted_error
def validate(*args, **kwargs):
try:
return validate_document(*args, **kwargs)
finally:
validation_aborted_error.__traceback__ = None
Pass this function instead of the original validate where your framework allows it.
Credits
Reported by @riodw. @Fire162 submitted a first fix in #288.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "graphql-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.3.0a3"
},
{
"fixed": "3.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-119286"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T22:58:31Z",
"nvd_published_at": "2026-10-29T22:17:01Z",
"severity": "HIGH"
},
"details": "### Summary\n\nWhen a validation was aborted because the document contained more errors than allowed by `max_errors` (100 by default), `validate()` raised a single module-level `ValidationAbortedError` instance. Python appends the frames of every `raise` to the existing `__traceback__` of an exception that is raised again, so every aborted validation extended the traceback of this shared error. That traceback kept the frames, and with them the document, the validation context and all errors of every aborted validation, alive for the lifetime of the process.\n\n### Details\n\nAny client can trigger an aborted validation by sending a small document with more than 100 validation errors, e.g. 101 unknown fields. No authentication is required, and since validation runs before execution, depth limiters and complexity analyzers do not prevent it. Each such request permanently retained about 124 KiB on CPython 3.12, without an upper limit, so memory grew with every request until the process was restarted or killed.\n\nGraphQL.js uses a shared error object at the same place, but JavaScript errors capture their stack trace only once when they are created, so it is not affected. GraphQL-core 3.2 creates a new error for each aborted validation and is not affected either.\n\n### Proof of concept\n\n```python\nimport gc\nimport tracemalloc\nfrom graphql import build_schema, parse, validate\n\nschema = build_schema(\"type Query { a: Int }\")\ndocument = parse(\"{ \" + \" \".join(f\"f{i}\" for i in range(101)) + \" }\")\n\ntracemalloc.start()\nvalidate(schema, document)\ngc.collect()\nbase = tracemalloc.get_traced_memory()[0]\nfor _ in range(200):\n validate(schema, document)\ngc.collect()\nprint((tracemalloc.get_traced_memory()[0] - base) // 1024, \"KiB\")\n```\n\nWith GraphQL-core 3.3.0 on CPython 3.12, the retained memory grows from 147 KiB after one call to about 25 MB after 200 calls. With the fix, it stays constant at about 180 KiB.\n\n### Impact\n\nDenial of service through memory exhaustion. A few thousand small requests are enough to push a worker past a typical 256 MB or 512 MB container limit and trigger an OOM kill. No data is disclosed or modified.\n\n### Patches\n\nFixed in **3.3.1**.\n\n`validate()` now creates a new `ValidationAbortedError` for every aborted validation and removes its traceback and exception context before returning it, so that the returned errors do not keep the frames of the validation alive. The module-level `validation_aborted_error` instance, which was not exported, has been removed.\n\n### Workarounds\n\nIf you cannot upgrade, clear the traceback of the shared error after each validation:\n\n```python\nfrom graphql.validation import validate as validate_document\nfrom graphql.validation.validate import validation_aborted_error\n\ndef validate(*args, **kwargs):\n try:\n return validate_document(*args, **kwargs)\n finally:\n validation_aborted_error.__traceback__ = None\n```\n\nPass this function instead of the original `validate` where your framework allows it.\n\n### Credits\n\nReported by @riodw. @Fire162 submitted a first fix in #288.",
"id": "GHSA-mpqx-q82w-9x46",
"modified": "2026-10-30T22:58:31Z",
"published": "2026-10-30T22:58:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/graphql-python/graphql-core/security/advisories/GHSA-mpqx-q82w-9x46"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-119286"
},
{
"type": "WEB",
"url": "https://github.com/graphql-python/graphql-core/issues/287"
},
{
"type": "WEB",
"url": "https://github.com/graphql-python/graphql-core/pull/288"
},
{
"type": "WEB",
"url": "https://github.com/graphql-python/graphql-core/commit/3c319fd9f4b8f6c9db4189520561bf8dd0e70be9"
},
{
"type": "PACKAGE",
"url": "https://github.com/graphql-python/graphql-core"
},
{
"type": "WEB",
"url": "https://github.com/graphql-python/graphql-core/releases/tag/v3.3.1"
}
],
"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"
}
],
"summary": "GraphQL-core has denial of service via memory leak in aborted validations"
}
GHSA-MQ3C-V59W-HJF6
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 15:30In the Linux kernel, the following vulnerability has been resolved:
drm/drm_vma_manager: Add drm_vma_node_allow_once()
Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. Allow drm drivers to call non-refcounted version of drm_vma_node_allow() so that a driver doesn't need to keep track of each drm_vma_node_allow() to call subsequent drm_vma_node_revoke() to prevent memory leak.
{
"affected": [],
"aliases": [
"CVE-2023-53001"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_vma_manager: Add drm_vma_node_allow_once()\n\nCurrently there is no easy way for a drm driver to safely check and allow\ndrm_vma_offset_node for a drm file just once. Allow drm drivers to call\nnon-refcounted version of drm_vma_node_allow() so that a driver doesn\u0027t\nneed to keep track of each drm_vma_node_allow() to call subsequent\ndrm_vma_node_revoke() to prevent memory leak.",
"id": "GHSA-mq3c-v59w-hjf6",
"modified": "2025-04-15T15:30:52Z",
"published": "2025-03-27T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53001"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67444f8ca31cdaf45e0b761241ad49b1ae04bcf9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/899d3a3c19ac0e5da013ce34833dccb97d19b5e4"
}
],
"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.