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-GR54-F9VX-R2H8
Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
staging: pi433: 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. This requires saving off the root directory dentry to make creation of individual device subdirectories easier.
{
"affected": [],
"aliases": [
"CVE-2023-53355"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-17T15:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: pi433: 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\nat once. This requires saving off the root directory dentry to make\ncreation of individual device subdirectories easier.",
"id": "GHSA-gr54-f9vx-r2h8",
"modified": "2025-12-11T15:30:30Z",
"published": "2025-09-17T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53355"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04f3cda40e9f6653ae15ed3fcf26ef2860f4df66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f36e789e540df6a9fbf471b3a2ba62a8b361586"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb16f3102607b69e1a0233f4b73c6e337f86ef8d"
}
],
"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-GR59-J2CC-29G3
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 21:31In the Linux kernel, the following vulnerability has been resolved:
Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()"
This reverts commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293.
ieee80211_if_free() is already called from free_netdev(ndev) because ndev->priv_destructor == ieee80211_if_free
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline] RIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline] RIP: 0010:free_percpu mm/percpu.c:2271 [inline] RIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254 Code: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc RSP: 0018:ffffc90004ba7068 EFLAGS: 00010002 RAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004 RDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020 RBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000 R13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988 FS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: netdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352 ieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411 mac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583 hwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176 genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968 genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline] netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 _syssendmsg+0x712/0x8c0 net/socket.c:2476 _sys_sendmsg+0x110/0x1b0 net/socket.c:2530 __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
{
"affected": [],
"aliases": [
"CVE-2023-53028"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"wifi: mac80211: fix memory leak in ieee80211_if_add()\"\n\nThis reverts commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293.\n\nieee80211_if_free() is already called from free_netdev(ndev)\nbecause ndev-\u003epriv_destructor == ieee80211_if_free\n\nsyzbot reported:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nCPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nRIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline]\nRIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline]\nRIP: 0010:free_percpu mm/percpu.c:2271 [inline]\nRIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254\nCode: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 \u003c80\u003e 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc\nRSP: 0018:ffffc90004ba7068 EFLAGS: 00010002\nRAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004\nRDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020\nRBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000\nR13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988\nFS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u003cTASK\u003e\nnetdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352\nieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411\nmac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583\nhwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176\ngenl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968\ngenl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]\ngenl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065\nnetlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564\ngenl_rcv+0x28/0x40 net/netlink/genetlink.c:1076\nnetlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]\nnetlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356\nnetlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932\nsock_sendmsg_nosec net/socket.c:714 [inline]\nsock_sendmsg+0xd3/0x120 net/socket.c:734\n____sys_sendmsg+0x712/0x8c0 net/socket.c:2476\n___sys_sendmsg+0x110/0x1b0 net/socket.c:2530\n__sys_sendmsg+0xf7/0x1c0 net/socket.c:2559\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd",
"id": "GHSA-gr59-j2cc-29g3",
"modified": "2025-04-15T21:31:31Z",
"published": "2025-03-27T18:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53028"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71e5cd1018d345e649e63f74a56c1897f99db7e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80f8a66dede0a4b4e9e846765a97809c6fe49ce5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/982c8b1e95c088f5d8f65967ec25be66e961401c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/effecd8d116d3d3a28b4f628e61bba8d318fdfcf"
}
],
"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-GV9G-CCX2-9XJ9
Vulnerability from github – Published: 2025-03-10 21:31 – Updated: 2025-03-10 21:31In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT
There is a potential memory leak in lpfc_ignore_els_cmpl() and lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT (lpfc_rcv_plogi()'s login_mbox).
Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(), and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for service parameters.
For lpfc_els_rsp_reject() failure, free both the ctx_buf for service parameters and the login_mbox.
{
"affected": [],
"aliases": [
"CVE-2022-49534"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT\n\nThere is a potential memory leak in lpfc_ignore_els_cmpl() and\nlpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT\n(lpfc_rcv_plogi()\u0027s login_mbox).\n\nCheck if cmdiocb-\u003econtext_un.mbox was allocated in lpfc_ignore_els_cmpl(),\nand then free it back to phba-\u003embox_mem_pool along with mbox-\u003ectx_buf for\nservice parameters.\n\nFor lpfc_els_rsp_reject() failure, free both the ctx_buf for service\nparameters and the login_mbox.",
"id": "GHSA-gv9g-ccx2-9xj9",
"modified": "2025-03-10T21:31:09Z",
"published": "2025-03-10T21:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/672d1cb40551ea9c95efad43ab6d45e4ab4e015f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c00df0f34a6d5e14da379f96ea67e501ce67b002"
}
],
"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-GVFQ-9HRF-2536
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 03:30In the Linux kernel, the following vulnerability has been resolved:
ext4: fix memory leak in ext4_ext_shift_extents()
In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak.
Fix this by jumping to the out label to ensure the path is properly released.
{
"affected": [],
"aliases": [
"CVE-2026-45948"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix memory leak in ext4_ext_shift_extents()\n\nIn ext4_ext_shift_extents(), if the extent is NULL in the while loop, the\nfunction returns immediately without releasing the path obtained via\next4_find_extent(), leading to a memory leak.\n\nFix this by jumping to the out label to ensure the path is properly\nreleased.",
"id": "GHSA-gvfq-9hrf-2536",
"modified": "2026-06-16T03:30:32Z",
"published": "2026-05-27T15:33:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45948"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12615ab4bfb69678e5d961b28bb70040299e51b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bce219ee5512cf179ba40cf114945a14a16e21f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f4b1052246ca646bb17bfe0f53df2fdf9729b58"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a79fde8db7eba7f1128d971ceba4e3c9ac84aec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e807cb8603b7664fa630a696cd891d9a03c248d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/afc5e61e1a07b2b833bd72cbee36ecce9cd901e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd7b52557e4a3ccd7595fdb3a585f1257de57935"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca81109d4a8f192dc1cbad4a1ee25246363c2833"
}
],
"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-GVG6-G9VQ-R6GW
Vulnerability from github – Published: 2022-11-01 19:00 – Updated: 2022-11-03 19:00Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by Xenstore quota.
{
"affected": [],
"aliases": [
"CVE-2022-42323"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-01T13:15:00Z",
"severity": "MODERATE"
},
"details": "Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by domain A letting domain B write into domain A\u0027s local Xenstore tree. Domain B can then create many nodes and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and over again an arbitrary number of nodes can be created, as Dom0\u0027s number of nodes isn\u0027t limited by Xenstore quota.",
"id": "GHSA-gvg6-g9vq-r6gw",
"modified": "2022-11-03T19:00:25Z",
"published": "2022-11-01T19:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42323"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YTMITQBGC23MSDHUCAPCVGLMVXIBXQTQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YZVXG7OOOXCX6VIPEMLFDPIPUTFAYWPE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZLI2NPNEH7CNJO3VZGQNOI4M4EWLNKPZ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YTMITQBGC23MSDHUCAPCVGLMVXIBXQTQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YZVXG7OOOXCX6VIPEMLFDPIPUTFAYWPE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZLI2NPNEH7CNJO3VZGQNOI4M4EWLNKPZ"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202402-07"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5272"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-419.txt"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/11/01/9"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-419.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-GVRM-XH5G-W8V6
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-06-28 09:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure
In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries.
With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind:
DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core]
Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.
{
"affected": [],
"aliases": [
"CVE-2026-53229"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:40Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure\n\nIn the XSK branch of mlx5e_xmit_xdp_buff(), when sq-\u003exmit_xdp_frame()\nreturns false (e.g. XDPSQ is full), the function returns without\nunmapping the DMA address or freeing the xdp_frame allocated by\nxdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on\nsuccess, so the completion path cannot recover these entries.\n\nWith CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind:\n\n DMA-API: pci 0000:08:00.0: device driver has pending DMA\n allocations while released from device [count=1116]\n One of leaked entries details: [device address=0x000000010ffd7028]\n [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy]\n WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180\n ...\n DMA-API: Mapped at:\n debug_dma_map_phys+0x4b/0xd0\n dma_map_phys+0xfd/0x2d0\n mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core]\n mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core]\n mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core]\n\nAdd the missing unmap + xdp_return_frame, matching the cleanup already\ndone in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch,\nso no per-frag unmap is needed.",
"id": "GHSA-gvrm-xh5g-w8v6",
"modified": "2026-06-28T09:31:45Z",
"published": "2026-06-25T09:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53229"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0aabca726b43d833721034e97d99efcc8237b22a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2789b74ae1f4b68333c9d5eec2f3354d07b16e61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b3eeba50fbc3b45f279037c29a87a90e8bac1e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b69004f5a6ad32da84d8aa5b23b9c0caafe6252e"
}
],
"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-GVVF-V7JC-239R
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
net: fix udp gso skb_segment after pull from frag_list
Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from frag_list") detected invalid geometry in frag_list skbs and redirects them from skb_segment_list to more robust skb_segment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skb_segment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust.
If only part of the fraglist payload is pulled into head_skb, it will always cause exception when splitting skbs by skb_segment. For detailed call stack information, see below.
Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size
Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify fraglist skbs, breaking these invariants.
In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes.
The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because payload was pulled into head_skb, it needs to be linearized before pass to regular skb_segment.
skb_segment+0xcd0/0xd14
__udp_gso_segment+0x334/0x5f4
udp4_ufo_fragment+0x118/0x15c
inet_gso_segment+0x164/0x338
skb_mac_gso_segment+0xc4/0x13c
__skb_gso_segment+0xc4/0x124
validate_xmit_skb+0x9c/0x2c0
validate_xmit_skb_list+0x4c/0x80
sch_direct_xmit+0x70/0x404
__dev_queue_xmit+0x64c/0xe5c
neigh_resolve_output+0x178/0x1c4
ip_finish_output2+0x37c/0x47c
__ip_finish_output+0x194/0x240
ip_finish_output+0x20/0xf4
ip_output+0x100/0x1a0
NF_HOOK+0xc4/0x16c
ip_forward+0x314/0x32c
ip_rcv+0x90/0x118
__netif_receive_skb+0x74/0x124
process_backlog+0xe8/0x1a4
__napi_poll+0x5c/0x1f8
net_rx_action+0x154/0x314
handle_softirqs+0x154/0x4b8
[118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278!
[118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000
[118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000
[118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO)
[118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14
[118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14
[118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770
{
"affected": [],
"aliases": [
"CVE-2025-38124"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix udp gso skb_segment after pull from frag_list\n\nCommit a1e40ac5b5e9 (\"net: gso: fix udp gso fraglist segmentation after\npull from frag_list\") detected invalid geometry in frag_list skbs and\nredirects them from skb_segment_list to more robust skb_segment. But some\npackets with modified geometry can also hit bugs in that code. We don\u0027t\nknow how many such cases exist. Addressing each one by one also requires\ntouching the complex skb_segment code, which risks introducing bugs for\nother types of skbs. Instead, linearize all these packets that fail the\nbasic invariants on gso fraglist skbs. That is more robust.\n\nIf only part of the fraglist payload is pulled into head_skb, it will\nalways cause exception when splitting skbs by skb_segment. For detailed\ncall stack information, see below.\n\nValid SKB_GSO_FRAGLIST skbs\n- consist of two or more segments\n- the head_skb holds the protocol headers plus first gso_size\n- one or more frag_list skbs hold exactly one segment\n- all but the last must be gso_size\n\nOptional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can\nmodify fraglist skbs, breaking these invariants.\n\nIn extreme cases they pull one part of data into skb linear. For UDP,\nthis causes three payloads with lengths of (11,11,10) bytes were\npulled tail to become (12,10,10) bytes.\n\nThe skbs no longer meets the above SKB_GSO_FRAGLIST conditions because\npayload was pulled into head_skb, it needs to be linearized before pass\nto regular skb_segment.\n\n skb_segment+0xcd0/0xd14\n __udp_gso_segment+0x334/0x5f4\n udp4_ufo_fragment+0x118/0x15c\n inet_gso_segment+0x164/0x338\n skb_mac_gso_segment+0xc4/0x13c\n __skb_gso_segment+0xc4/0x124\n validate_xmit_skb+0x9c/0x2c0\n validate_xmit_skb_list+0x4c/0x80\n sch_direct_xmit+0x70/0x404\n __dev_queue_xmit+0x64c/0xe5c\n neigh_resolve_output+0x178/0x1c4\n ip_finish_output2+0x37c/0x47c\n __ip_finish_output+0x194/0x240\n ip_finish_output+0x20/0xf4\n ip_output+0x100/0x1a0\n NF_HOOK+0xc4/0x16c\n ip_forward+0x314/0x32c\n ip_rcv+0x90/0x118\n __netif_receive_skb+0x74/0x124\n process_backlog+0xe8/0x1a4\n __napi_poll+0x5c/0x1f8\n net_rx_action+0x154/0x314\n handle_softirqs+0x154/0x4b8\n\n [118.376811] [C201134] rxq0_pus: [name:bug\u0026]kernel BUG at net/core/skbuff.c:4278!\n [118.376829] [C201134] rxq0_pus: [name:traps\u0026]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n [118.470774] [C201134] rxq0_pus: [name:mrdump\u0026]Kernel Offset: 0x178cc00000 from 0xffffffc008000000\n [118.470810] [C201134] rxq0_pus: [name:mrdump\u0026]PHYS_OFFSET: 0x40000000\n [118.470827] [C201134] rxq0_pus: [name:mrdump\u0026]pstate: 60400005 (nZCv daif +PAN -UAO)\n [118.470848] [C201134] rxq0_pus: [name:mrdump\u0026]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14\n [118.470900] [C201134] rxq0_pus: [name:mrdump\u0026]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14\n [118.470928] [C201134] rxq0_pus: [name:mrdump\u0026]sp : ffffffc008013770",
"id": "GHSA-gvvf-v7jc-239r",
"modified": "2026-05-12T15:30:54Z",
"published": "2025-07-03T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38124"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e65f38bd1aa14ea86e221b7bb814d38278d86c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3382a1ed7f778db841063f5d7e317ac55f9e7f72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4399f59a9467a324ed46657555f0e1f209a14acb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85eef1748c024da1a191aed56b30a3a65958c50c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a04302867094bdc6efac1b598370fc47cf3f2388"
},
{
"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-GVWX-6CPM-MJRJ
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-09-17 15:30In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix kernel crash during resume
Currently during resume, QMI target memory is not properly handled, resulting in kernel crash in case DMA remap is not supported:
BUG: Bad page state in process kworker/u16:54 pfn:36e80 page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80 page dumped because: nonzero _refcount Call Trace: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs ath12k_qmi_free_target_mem_chunk ath12k_qmi_msg_mem_request_cb
The reason is: Once ath12k module is loaded, firmware sends memory request to host. In case DMA remap not supported, ath12k refuses the first request due to failure in allocating with large segment size:
ath12k_pci 0000:04:00.0: qmi firmware request memory request ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144 ath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size ath12k_pci 0000:04:00.0: qmi delays mem_request 2 ath12k_pci 0000:04:00.0: qmi firmware request memory request
Later firmware comes back with more but small segments and allocation succeeds:
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
Now ath12k is working. If suspend is triggered, firmware will be reloaded during resume. As same as before, firmware requests two large segments at first. In ath12k_qmi_msg_mem_request_cb() segment count and size are assigned:
ab->qmi.mem_seg_count == 2
ab->qmi.target_mem[0].size == 7077888
ab->qmi.target_mem[1].size == 8454144
Then allocation failed like before and ath12k_qmi_free_target_mem_chunk() is called to free all allocated segments. Note the first segment is skipped because its v.addr is cleared due to allocation failure:
chunk->v.addr = dma_alloc_coherent()
Also note that this leaks that segment because it has not been freed.
While freeing the second segment, a size of 8454144 is passed to dma_free_coherent(). However remember that this segment is allocated at the first time firmware is loaded, before suspend. So its real size is 524288, much smaller than 8454144. As a result kernel found we are freeing some memory which is in use and thus cras ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-40979"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix kernel crash during resume\n\nCurrently during resume, QMI target memory is not properly handled, resulting\nin kernel crash in case DMA remap is not supported:\n\nBUG: Bad page state in process kworker/u16:54 pfn:36e80\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80\npage dumped because: nonzero _refcount\nCall Trace:\n bad_page\n free_page_is_bad_report\n __free_pages_ok\n __free_pages\n dma_direct_free\n dma_free_attrs\n ath12k_qmi_free_target_mem_chunk\n ath12k_qmi_msg_mem_request_cb\n\nThe reason is:\nOnce ath12k module is loaded, firmware sends memory request to host. In case\nDMA remap not supported, ath12k refuses the first request due to failure in\nallocating with large segment size:\n\nath12k_pci 0000:04:00.0: qmi firmware request memory request\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144\nath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size\nath12k_pci 0000:04:00.0: qmi delays mem_request 2\nath12k_pci 0000:04:00.0: qmi firmware request memory request\n\nLater firmware comes back with more but small segments and allocation\nsucceeds:\n\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\n\nNow ath12k is working. If suspend is triggered, firmware will be reloaded\nduring resume. As same as before, firmware requests two large segments at\nfirst. In ath12k_qmi_msg_mem_request_cb() segment count and size are\nassigned:\n\n\tab-\u003eqmi.mem_seg_count == 2\n\tab-\u003eqmi.target_mem[0].size == 7077888\n\tab-\u003eqmi.target_mem[1].size == 8454144\n\nThen allocation failed like before and ath12k_qmi_free_target_mem_chunk()\nis called to free all allocated segments. Note the first segment is skipped\nbecause its v.addr is cleared due to allocation failure:\n\n\tchunk-\u003ev.addr = dma_alloc_coherent()\n\nAlso note that this leaks that segment because it has not been freed.\n\nWhile freeing the second segment, a size of 8454144 is passed to\ndma_free_coherent(). However remember that this segment is allocated at\nthe first time firmware is loaded, before suspend. So its real size is\n524288, much smaller than 8454144. As a result kernel found we are freeing\nsome memory which is in use and thus cras\n---truncated---",
"id": "GHSA-gvwx-6cpm-mjrj",
"modified": "2025-09-17T15:30:26Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40979"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/303c017821d88ebad887814114d4e5966d320b28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb50a4e711ff95348ad53641acb1306d89eb4c3a"
}
],
"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-GW7V-Q6J5-H9MV
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 15:30In the Linux kernel, the following vulnerability has been resolved:
USB: dwc3: 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.
Note, the root dentry for the debugfs directory for the device needs to be saved so we don't have to keep looking it up, which required a bit more refactoring to properly create and remove it when needed.
{
"affected": [],
"aliases": [
"CVE-2023-53415"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: dwc3: 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\nat once.\n\nNote, the root dentry for the debugfs directory for the device needs to\nbe saved so we don\u0027t have to keep looking it up, which required a bit\nmore refactoring to properly create and remove it when needed.",
"id": "GHSA-gw7v-q6j5-h9mv",
"modified": "2025-12-11T15:30:30Z",
"published": "2025-09-18T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53415"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bab872b638130a18fd54d9adfad7db77ed6457be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be308d68785b205e483b3a0c61ba3a82da468f2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce234af49d103d95e3fdca59b25e0d0242f41bb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf52c320cf74245ce1c12b0bd48f77b87d77fbc9"
}
],
"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-GW83-JH7X-85P6
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
gpib: Fix memory leak in ni_usb_init()
In ni_usb_init(), if ni_usb_setup_init() fails, the function returns -EFAULT without freeing the allocated writes buffer, leading to a memory leak.
Additionally, ni_usb_setup_init() returns 0 on failure, which causes ni_usb_init() to return -EFAULT, an inappropriate error code for this situation.
Fix the leak by freeing writes in the error path. Modify ni_usb_setup_init() to return -EINVAL on failure and propagate this error code in ni_usb_init().
{
"affected": [],
"aliases": [
"CVE-2026-45939"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpib: Fix memory leak in ni_usb_init()\n\nIn ni_usb_init(), if ni_usb_setup_init() fails, the function returns\n-EFAULT without freeing the allocated writes buffer, leading to a\nmemory leak.\n\nAdditionally, ni_usb_setup_init() returns 0 on failure, which causes\nni_usb_init() to return -EFAULT, an inappropriate error code for this\nsituation.\n\nFix the leak by freeing writes in the error path. Modify\nni_usb_setup_init() to return -EINVAL on failure and propagate this\nerror code in ni_usb_init().",
"id": "GHSA-gw83-jh7x-85p6",
"modified": "2026-06-24T18:32:28Z",
"published": "2026-05-27T15:33:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45939"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c97fcfb7a62dea893104a046d544da8ac23370b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b89921eed8cf2d97250bac4be38dbcfbf048b586"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c899d4b62c0757a280831e89c1f3801b597e8f38"
}
],
"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.