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.
2125 vulnerabilities reference this CWE, most recent first.
GHSA-Q7HG-QX63-Q53R
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
usb: ulpi: fix memory leak on ulpi_register() error paths
Commit 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") removed kfree(ulpi) from ulpi_register_interface() to fix a double-free when device_register() fails.
But when ulpi_of_register() or ulpi_read_id() fail before device_register() is called, the ulpi allocation is leaked.
Add kfree(ulpi) on both error paths to properly clean up the allocation.
{
"affected": [],
"aliases": [
"CVE-2026-46109"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: ulpi: fix memory leak on ulpi_register() error paths\n\nCommit 01af542392b5 (\"usb: ulpi: fix double free in\nulpi_register_interface() error path\") removed kfree(ulpi) from\nulpi_register_interface() to fix a double-free when device_register()\nfails.\n\nBut when ulpi_of_register() or ulpi_read_id() fail before\ndevice_register() is called, the ulpi allocation is leaked.\n\nAdd kfree(ulpi) on both error paths to properly clean up the allocation.",
"id": "GHSA-q7hg-qx63-q53r",
"modified": "2026-06-24T18:32:31Z",
"published": "2026-05-28T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46109"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b9fcab1b8608d429e5f239afb197de928d4de7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c2c0c6820fe96fa4be0a0499f8d3f3321b9af6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a71e01b2cf9b4329ff67102c1bea7448c2a2d2d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bd61ed0bf9f4f1f2673d489b3bda1555b48d054"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0c0d44adb55c66663886cb6e30ee92cbb0f5385"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be2c1d825f54277472c87019e82013ac534ddc4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1b855c00988a9cb41134cab7cf9faedba775dd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f30ccfc2985590b33a23a3d8bed7ca16c0af551b"
}
],
"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-Q7RM-C66R-G7QX
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2022-05-24 16:58A memory leak vulnerability in the of Juniper Networks Junos OS allows an attacker to cause a Denial of Service (DoS) to the device by sending specific commands from a peered BGP host and having those BGP states delivered to the vulnerable device. This issue affects: Juniper Networks Junos OS: 18.1 versions prior to 18.1R2-S4, 18.1R3-S1; 18.1X75 all versions. Versions before 18.1R1 are not affected.
{
"affected": [],
"aliases": [
"CVE-2019-0059"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-09T20:15:00Z",
"severity": "HIGH"
},
"details": "A memory leak vulnerability in the of Juniper Networks Junos OS allows an attacker to cause a Denial of Service (DoS) to the device by sending specific commands from a peered BGP host and having those BGP states delivered to the vulnerable device. This issue affects: Juniper Networks Junos OS: 18.1 versions prior to 18.1R2-S4, 18.1R3-S1; 18.1X75 all versions. Versions before 18.1R1 are not affected.",
"id": "GHSA-q7rm-c66r-g7qx",
"modified": "2022-05-24T16:58:12Z",
"published": "2022-05-24T16:58:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0059"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA10957"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-Q867-J66R-989P
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2023-01-17 21:30A memory leak in the ath9k_wmi_cmd() function in drivers/net/wireless/ath/ath9k/wmi.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-728c1e2a05e4.
{
"affected": [],
"aliases": [
"CVE-2019-19074"
],
"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 ath9k_wmi_cmd() function in drivers/net/wireless/ath/ath9k/wmi.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-728c1e2a05e4.",
"id": "GHSA-q867-j66r-989p",
"modified": "2023-01-17T21:30:19Z",
"published": "2022-05-24T17:01:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19074"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/728c1e2a05e4b5fc52fab3421dce772a806612a2"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00032.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00034.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://security.netapp.com/advisory/ntap-20191205-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4526-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4527-1"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"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-Q8CJ-QGWH-M89M
Vulnerability from github – Published: 2024-05-03 18:30 – Updated: 2025-09-18 18:30In the Linux kernel, the following vulnerability has been resolved:
sched/debug: fix dentry leak in update_sched_domain_debugfs
Kuyo reports that the pattern of using debugfs_remove(debugfs_lookup()) leaks a dentry and with a hotplug stress test, the machine eventually runs out of memory.
Fix this up by using the newly created debugfs_lookup_and_remove() call instead which properly handles the dentry reference counting logic.
{
"affected": [],
"aliases": [
"CVE-2022-48699"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T16:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/debug: fix dentry leak in update_sched_domain_debugfs\n\nKuyo reports that the pattern of using debugfs_remove(debugfs_lookup())\nleaks a dentry and with a hotplug stress test, the machine eventually\nruns out of memory.\n\nFix this up by using the newly created debugfs_lookup_and_remove() call\ninstead which properly handles the dentry reference counting logic.",
"id": "GHSA-q8cj-qgwh-m89m",
"modified": "2025-09-18T18:30:21Z",
"published": "2024-05-03T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48699"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c32a93963e03c03e561d5a066eedad211880ba3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26e9a1ded8923510e5529fbb28390b22228700c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2e406596571659451f4b95e37ddfd5a8ef1d0dc"
}
],
"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-Q8GH-4J4R-HP3V
Vulnerability from github – Published: 2022-05-13 01:13 – Updated: 2022-05-13 01:13Memory leak in hw/audio/ac97.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption and QEMU process crash) via a large number of device unplug operations.
{
"affected": [],
"aliases": [
"CVE-2017-5525"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-15T15:59:00Z",
"severity": "MODERATE"
},
"details": "Memory leak in hw/audio/ac97.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption and QEMU process crash) via a large number of device unplug operations.",
"id": "GHSA-q8gh-4j4r-hp3v",
"modified": "2022-05-13T01:13:41Z",
"published": "2022-05-13T01:13:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5525"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00007.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201702-28"
},
{
"type": "WEB",
"url": "http://git.qemu-project.org/?p=qemu.git%3Ba=commit%3Bh=12351a91da97b414eec8cdb09f1d9f41e535a401"
},
{
"type": "WEB",
"url": "http://git.qemu-project.org/?p=qemu.git;a=commit;h=12351a91da97b414eec8cdb09f1d9f41e535a401"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2017/01/17/19"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2017/01/18/7"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95671"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q8PM-H92V-PX9X
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in sk_psock_queue_msg
If tcp_bpf_sendmsg is running during a tear down operation we may enqueue data on the ingress msg queue while tear down is trying to free it.
sk1 (redirect sk2) sk2 ------------------- --------------- tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... blocking sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock()
While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge and has sg pages need to put. To fix we use sk_msg_free() and then kfee() msg.
This issue can cause the following info: WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0 Call Trace: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90
WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0 Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
{
"affected": [],
"aliases": [
"CVE-2022-49207"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix memleak in sk_psock_queue_msg\n\nIf tcp_bpf_sendmsg is running during a tear down operation we may enqueue\ndata on the ingress msg queue while tear down is trying to free it.\n\n sk1 (redirect sk2) sk2\n ------------------- ---------------\ntcp_bpf_sendmsg()\n tcp_bpf_send_verdict()\n tcp_bpf_sendmsg_redir()\n bpf_tcp_ingress()\n sock_map_close()\n lock_sock()\n lock_sock() ... blocking\n sk_psock_stop\n sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);\n release_sock(sk);\n lock_sock()\n sk_mem_charge()\n get_page()\n sk_psock_queue_msg()\n sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);\n drop_sk_msg()\n release_sock()\n\nWhile drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge\nand has sg pages need to put. To fix we use sk_msg_free() and then kfee()\nmsg.\n\nThis issue can cause the following info:\nWARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0\nCall Trace:\n \u003cIRQ\u003e\n inet_csk_destroy_sock+0x55/0x110\n tcp_rcv_state_process+0xe5f/0xe90\n ? sk_filter_trim_cap+0x10d/0x230\n ? tcp_v4_do_rcv+0x161/0x250\n tcp_v4_do_rcv+0x161/0x250\n tcp_v4_rcv+0xc3a/0xce0\n ip_protocol_deliver_rcu+0x3d/0x230\n ip_local_deliver_finish+0x54/0x60\n ip_local_deliver+0xfd/0x110\n ? ip_protocol_deliver_rcu+0x230/0x230\n ip_rcv+0xd6/0x100\n ? ip_local_deliver+0x110/0x110\n __netif_receive_skb_one_core+0x85/0xa0\n process_backlog+0xa4/0x160\n __napi_poll+0x29/0x1b0\n net_rx_action+0x287/0x300\n __do_softirq+0xff/0x2fc\n do_softirq+0x79/0x90\n \u003c/IRQ\u003e\n\nWARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0\nCall Trace:\n \u003cTASK\u003e\n __sk_destruct+0x24/0x1f0\n sk_psock_destroy+0x19b/0x1c0\n process_one_work+0x1b3/0x3c0\n ? process_one_work+0x3c0/0x3c0\n worker_thread+0x30/0x350\n ? process_one_work+0x3c0/0x3c0\n kthread+0xe6/0x110\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e",
"id": "GHSA-q8pm-h92v-px9x",
"modified": "2025-03-18T21:31:59Z",
"published": "2025-03-18T21:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03948ed6553960db62f1c33bec29e64d7c191a3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4dd2e947d3be13a4de3b3028859b9a6497266bcf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/938d3480b92fa5e454b7734294f12a7b75126f09"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef9785f429794567792561a584901faa9291d3ee"
}
],
"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-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"
}
]
}
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.