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.
2031 vulnerabilities reference this CWE, most recent first.
GHSA-C5XH-C73J-MCX2
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-25 21:31In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix memleak of newsk in unix_stream_connect().
When prepare_peercred() fails in unix_stream_connect(), unix_release_sock() is not called for newsk, and the memory is leaked.
Let's move prepare_peercred() before unix_create1().
{
"affected": [],
"aliases": [
"CVE-2026-45887"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix memleak of newsk in unix_stream_connect().\n\nWhen prepare_peercred() fails in unix_stream_connect(),\nunix_release_sock() is not called for newsk, and the memory\nis leaked.\n\nLet\u0027s move prepare_peercred() before unix_create1().",
"id": "GHSA-c5xh-c73j-mcx2",
"modified": "2026-06-25T21:31:20Z",
"published": "2026-05-27T15:33:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45887"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/365996a2b14d07caa9e33d367b67ea26c09d89b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6884028cd7f275f8bcb854a347265cb1fb0e4bea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5d95d7caba0160fb7b2b8d2bd96d5a1be861d9f"
}
],
"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-C62G-6HM9-X69Q
Vulnerability from github – Published: 2024-12-29 09:30 – Updated: 2025-01-06 18:31In the Linux kernel, the following vulnerability has been resolved:
ceph: fix memory leak in ceph_direct_read_write()
The bvecs array which is allocated in iter_get_bvecs_alloc() is leaked and pages remain pinned if ceph_alloc_sparse_ext_map() fails.
There is no need to delay the allocation of sparse_ext map until after the bvecs array is set up, so fix this by moving sparse_ext allocation a bit earlier. Also, make a similar adjustment in __ceph_sync_read() for consistency (a leak of the same kind in __ceph_sync_read() has been addressed differently).
{
"affected": [],
"aliases": [
"CVE-2024-56710"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T09:15:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix memory leak in ceph_direct_read_write()\n\nThe bvecs array which is allocated in iter_get_bvecs_alloc() is leaked\nand pages remain pinned if ceph_alloc_sparse_ext_map() fails.\n\nThere is no need to delay the allocation of sparse_ext map until after\nthe bvecs array is set up, so fix this by moving sparse_ext allocation\na bit earlier. Also, make a similar adjustment in __ceph_sync_read()\nfor consistency (a leak of the same kind in __ceph_sync_read() has been\naddressed differently).",
"id": "GHSA-c62g-6hm9-x69q",
"modified": "2025-01-06T18:31:01Z",
"published": "2024-12-29T09:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56710"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44e518abbb498075ae85c7d1d1a503a6bb05ea2d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66e0c4f91461d17d48071695271c824620bed4ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb9041837123f31d5897e99bb761f46cb4ce5859"
}
],
"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-C655-QWVW-WFQM
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2025-04-29 21:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix page reclaim for dead peer hairpin
When adding a hairpin flow, a firmware-side send queue is created for the peer net device, which claims some host memory pages for its internal ring buffer. If the peer net device is removed/unbound before the hairpin flow is deleted, then the send queue is not destroyed which leads to a stack trace on pci device remove:
[ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource [ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110 [ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0 [ 748.002171] ------------[ cut here ]------------ [ 748.001177] FW pages counter is 4 after reclaiming all pages [ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core] [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1 [ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9 [ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286 [ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000 [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51 [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8 [ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30 [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000 [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000 [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0 [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 748.001654] Call Trace: [ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core] [ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core] [ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core] [ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core] [ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core] [ 748.001200] remove_one+0x5f/0xc0 [mlx5_core] [ 748.001075] pci_device_remove+0x9f/0x1d0 [ 748.000833] device_release_driver_internal+0x1e0/0x490 [ 748.001207] unbind_store+0x19f/0x200 [ 748.000942] ? sysfs_file_ops+0x170/0x170 [ 748.001000] kernfs_fop_write_iter+0x2bc/0x450 [ 748.000970] new_sync_write+0x373/0x610 [ 748.001124] ? new_sync_read+0x600/0x600 [ 748.001057] ? lock_acquire+0x4d6/0x700 [ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400 [ 748.001126] ? fd_install+0x1c9/0x4d0 [ 748.000951] vfs_write+0x4d0/0x800 [ 748.000804] ksys_write+0xf9/0x1d0 [ 748.000868] ? __x64_sys_read+0xb0/0xb0 [ 748.000811] ? filp_open+0x50/0x50 [ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50 [ 748.001223] do_syscall_64+0x3f/0x80 [ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 748.00 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2021-47246"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix page reclaim for dead peer hairpin\n\nWhen adding a hairpin flow, a firmware-side send queue is created for\nthe peer net device, which claims some host memory pages for its\ninternal ring buffer. If the peer net device is removed/unbound before\nthe hairpin flow is deleted, then the send queue is not destroyed which\nleads to a stack trace on pci device remove:\n\n[ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource\n[ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110\n[ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0\n[ 748.002171] ------------[ cut here ]------------\n[ 748.001177] FW pages counter is 4 after reclaiming all pages\n[ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core]\n[ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1\n[ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core]\n[ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 \u003c0f\u003e 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9\n[ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286\n[ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000\n[ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51\n[ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8\n[ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30\n[ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000\n[ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000\n[ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0\n[ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 748.001654] Call Trace:\n[ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core]\n[ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core]\n[ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core]\n[ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core]\n[ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core]\n[ 748.001200] remove_one+0x5f/0xc0 [mlx5_core]\n[ 748.001075] pci_device_remove+0x9f/0x1d0\n[ 748.000833] device_release_driver_internal+0x1e0/0x490\n[ 748.001207] unbind_store+0x19f/0x200\n[ 748.000942] ? sysfs_file_ops+0x170/0x170\n[ 748.001000] kernfs_fop_write_iter+0x2bc/0x450\n[ 748.000970] new_sync_write+0x373/0x610\n[ 748.001124] ? new_sync_read+0x600/0x600\n[ 748.001057] ? lock_acquire+0x4d6/0x700\n[ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400\n[ 748.001126] ? fd_install+0x1c9/0x4d0\n[ 748.000951] vfs_write+0x4d0/0x800\n[ 748.000804] ksys_write+0xf9/0x1d0\n[ 748.000868] ? __x64_sys_read+0xb0/0xb0\n[ 748.000811] ? filp_open+0x50/0x50\n[ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50\n[ 748.001223] do_syscall_64+0x3f/0x80\n[ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 748.00\n---truncated---",
"id": "GHSA-c655-qwvw-wfqm",
"modified": "2025-04-29T21:31:35Z",
"published": "2024-05-21T15:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47246"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b16118665e94c90a3e84a5190486fd0e4eedd74"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3e5fd9314dfc4314a9567cde96e1aef83a7458a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b374c1304f6d3d4752ad1412427b7bf02bb1fd61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be7f3f401d224e1efe8112b2fa8b837eeb8c5e52"
}
],
"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-C6G6-J52P-PG8H
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
ax25: properly unshare skbs in ax25_kiss_rcv()
Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d ("net: introduce per netns packet chains").
skb->dev becomes NULL and we crash in __netif_receive_skb_core().
Before above commit, different kind of bugs or corruptions could happen without a major crash.
But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not.
Many thanks to Bernard Pidoux for his help, diagnosis and tests.
We had a similar issue years ago fixed with commit 7aaed57c5c28 ("phonet: properly unshare skbs in phonet_rcv()").
{
"affected": [],
"aliases": [
"CVE-2025-39848"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-19T16:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nax25: properly unshare skbs in ax25_kiss_rcv()\n\nBernard Pidoux reported a regression apparently caused by commit\nc353e8983e0d (\"net: introduce per netns packet chains\").\n\nskb-\u003edev becomes NULL and we crash in __netif_receive_skb_core().\n\nBefore above commit, different kind of bugs or corruptions could happen\nwithout a major crash.\n\nBut the root cause is that ax25_kiss_rcv() can queue/mangle input skb\nwithout checking if this skb is shared or not.\n\nMany thanks to Bernard Pidoux for his help, diagnosis and tests.\n\nWe had a similar issue years ago fixed with commit 7aaed57c5c28\n(\"phonet: properly unshare skbs in phonet_rcv()\").",
"id": "GHSA-c6g6-j52p-pg8h",
"modified": "2026-05-12T15:31:10Z",
"published": "2025-09-22T21:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39848"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/01a2984cb803f2d487b7074f9718db2bf3531f69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2bd0f67212908243ce88e35bf69fa77155b47b14"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42b46684e2c78ee052d8c2ee8d9c2089233c9094"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b079be1b9da49ad88fc304c874d4be7085f7883"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d449b7a6c8ee434d10a483feed7c5c50108cf56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8156210d36a43e76372312c87eb5ea3dbb405a85"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89064cf534bea4bb28c83fe6bbb26657b19dd5fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1c71d674a308d2fbc83efcf88bfc4217a86aa17"
},
{
"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-C6PP-JFQW-H5C6
Vulnerability from github – Published: 2024-05-19 09:34 – Updated: 2025-09-23 15:31In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix Rx DMA datasize and skb_over_panic
mana_get_rxbuf_cfg() aligns the RX buffer's DMA datasize to be multiple of 64. So a packet slightly bigger than mtu+14, say 1536, can be received and cause skb_over_panic.
Sample dmesg: [ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev: [ 5325.243689] ------------[ cut here ]------------ [ 5325.245748] kernel BUG at net/core/skbuff.c:192! [ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60 [ 5325.302941] Call Trace: [ 5325.304389] [ 5325.315794] ? skb_panic+0x4f/0x60 [ 5325.317457] ? asm_exc_invalid_op+0x1f/0x30 [ 5325.319490] ? skb_panic+0x4f/0x60 [ 5325.321161] skb_put+0x4e/0x50 [ 5325.322670] mana_poll+0x6fa/0xb50 [mana] [ 5325.324578] __napi_poll+0x33/0x1e0 [ 5325.326328] net_rx_action+0x12e/0x280
As discussed internally, this alignment is not necessary. To fix this bug, remove it from the code. So oversized packets will be marked as CQE_RX_TRUNCATED by NIC, and dropped.
{
"affected": [],
"aliases": [
"CVE-2024-35901"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-19T09:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix Rx DMA datasize and skb_over_panic\n\nmana_get_rxbuf_cfg() aligns the RX buffer\u0027s DMA datasize to be\nmultiple of 64. So a packet slightly bigger than mtu+14, say 1536,\ncan be received and cause skb_over_panic.\n\nSample dmesg:\n[ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:\u003cNULL\u003e\n[ 5325.243689] ------------[ cut here ]------------\n[ 5325.245748] kernel BUG at net/core/skbuff.c:192!\n[ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60\n[ 5325.302941] Call Trace:\n[ 5325.304389] \u003cIRQ\u003e\n[ 5325.315794] ? skb_panic+0x4f/0x60\n[ 5325.317457] ? asm_exc_invalid_op+0x1f/0x30\n[ 5325.319490] ? skb_panic+0x4f/0x60\n[ 5325.321161] skb_put+0x4e/0x50\n[ 5325.322670] mana_poll+0x6fa/0xb50 [mana]\n[ 5325.324578] __napi_poll+0x33/0x1e0\n[ 5325.326328] net_rx_action+0x12e/0x280\n\nAs discussed internally, this alignment is not necessary. To fix\nthis bug, remove it from the code. So oversized packets will be\nmarked as CQE_RX_TRUNCATED by NIC, and dropped.",
"id": "GHSA-c6pp-jfqw-h5c6",
"modified": "2025-09-23T15:31:04Z",
"published": "2024-05-19T09:34:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35901"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/05cb7c41fa1a7a7b2c2a6b81bbe7c67f5c11932b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0de6ab920aafb56feab56058e46b688e694a246"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca58927b00385005f488b6a9905ced7a4f719aad"
}
],
"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-C6PQ-53V5-WCC7
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.
{
"affected": [],
"aliases": [
"CVE-2025-23160"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.",
"id": "GHSA-c6pq-53v5-wcc7",
"modified": "2026-05-12T15:30:52Z",
"published": "2025-05-01T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4936cd5817af35d23e4d283f48fa59a18ef481e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69dd5bbdd79c65445bb17c3c53510783bc1d756c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f009fa823c54ca0857c81f7525ea5a5d32de29c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac94e1db4b2053059779472eb58a64d504964240"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6cb086aa52bd51378a4c9e2b25d2def97770205"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd7bb97ede487b9f075707b7408a9073e0d474b1"
},
{
"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-C7CF-43WQ-XWRQ
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-11-07 19:00A memory leak in the i2400m_op_rfkill_sw_toggle() function in drivers/net/wimax/i2400m/op-rfkill.c in the Linux kernel before 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-6f3ef5c25cc7.
{
"affected": [],
"aliases": [
"CVE-2019-19051"
],
"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 i2400m_op_rfkill_sw_toggle() function in drivers/net/wimax/i2400m/op-rfkill.c in the Linux kernel before 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-6f3ef5c25cc7.",
"id": "GHSA-c7cf-43wq-xwrq",
"modified": "2022-11-07T19:00:22Z",
"published": "2022-05-24T17:01:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19051"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/6f3ef5c25cc762687a7341c18cbea5af54461407"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.3.11"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/01/msg00013.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191205-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4225-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4225-2"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4286-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4286-2"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4302-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4344-1"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00021.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-C7CG-C752-Q6Q2
Vulnerability from github – Published: 2024-11-09 12:30 – Updated: 2024-11-14 18:30In the Linux kernel, the following vulnerability has been resolved:
bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()
bpf_iter_bits_destroy() uses "kit->nr_bits <= 64" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below:
unreferenced object 0xffff88812628c8c0 (size 32): comm "swapper/0", pid 1, jiffies 4294727320 hex dump (first 32 bytes): b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): [<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 [<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 [<00000000597124d6>] __alloc.isra.0+0x89/0xb0 [<000000004ebfffcd>] alloc_bulk+0x2af/0x720 [<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 [<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 [<000000008b616eac>] bpf_global_ma_init+0x19/0x30 [<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 [<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 [<00000000b119f72f>] kernel_init+0x20/0x160 [<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 [<0000000004671da4>] ret_from_fork_asm+0x1a/0x30
That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated.
Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use "!nr_bits || bits >= nr_bits" to check whether the iteration is complete and still use "nr_bits > 64" to indicate whether bits are dynamically allocated. The "!nr_bits" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits.
Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.
{
"affected": [],
"aliases": [
"CVE-2024-50254"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T11:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Free dynamically allocated bits in bpf_iter_bits_destroy()\n\nbpf_iter_bits_destroy() uses \"kit-\u003enr_bits \u003c= 64\" to check whether the\nbits are dynamically allocated. However, the check is incorrect and may\ncause a kmemleak as shown below:\n\nunreferenced object 0xffff88812628c8c0 (size 32):\n comm \"swapper/0\", pid 1, jiffies 4294727320\n hex dump (first 32 bytes):\n\tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U...........\n\tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 ..............\n backtrace (crc 781e32cc):\n\t[\u003c00000000c452b4ab\u003e] kmemleak_alloc+0x4b/0x80\n\t[\u003c0000000004e09f80\u003e] __kmalloc_node_noprof+0x480/0x5c0\n\t[\u003c00000000597124d6\u003e] __alloc.isra.0+0x89/0xb0\n\t[\u003c000000004ebfffcd\u003e] alloc_bulk+0x2af/0x720\n\t[\u003c00000000d9c10145\u003e] prefill_mem_cache+0x7f/0xb0\n\t[\u003c00000000ff9738ff\u003e] bpf_mem_alloc_init+0x3e2/0x610\n\t[\u003c000000008b616eac\u003e] bpf_global_ma_init+0x19/0x30\n\t[\u003c00000000fc473efc\u003e] do_one_initcall+0xd3/0x3c0\n\t[\u003c00000000ec81498c\u003e] kernel_init_freeable+0x66a/0x940\n\t[\u003c00000000b119f72f\u003e] kernel_init+0x20/0x160\n\t[\u003c00000000f11ac9a7\u003e] ret_from_fork+0x3c/0x70\n\t[\u003c0000000004671da4\u003e] ret_from_fork_asm+0x1a/0x30\n\nThat is because nr_bits will be set as zero in bpf_iter_bits_next()\nafter all bits have been iterated.\n\nFix the issue by setting kit-\u003ebit to kit-\u003enr_bits instead of setting\nkit-\u003enr_bits to zero when the iteration completes in\nbpf_iter_bits_next(). In addition, use \"!nr_bits || bits \u003e= nr_bits\" to\ncheck whether the iteration is complete and still use \"nr_bits \u003e 64\" to\nindicate whether bits are dynamically allocated. The \"!nr_bits\" check is\nnecessary because bpf_iter_bits_new() may fail before setting\nkit-\u003enr_bits, and this condition will stop the iteration early instead\nof accessing the zeroed or freed kit-\u003ebits.\n\nConsidering the initial value of kit-\u003ebits is -1 and the type of\nkit-\u003enr_bits is unsigned int, change the type of kit-\u003enr_bits to int.\nThe potential overflow problem will be handled in the following patch.",
"id": "GHSA-c7cg-c752-q6q2",
"modified": "2024-11-14T18:30:32Z",
"published": "2024-11-09T12:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50254"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/101ccfbabf4738041273ce64e2b116cf440dea13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9cee266fafaf79fd465314546f637f9a3c215830"
}
],
"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-C7CV-93JX-FC79
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-10 21:31In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: fix empty payload in tap skb for non-linear buffers
For non-linear skbs, virtio_transport_build_skb() goes through virtio_transport_copy_nonlinear_skb() to copy the original payload in the new skb to be delivered to the vsockmon tap device. This manually initializes an iov_iter but does not set iov_iter.count. Since the iov_iter is zero-initialized, the copy length is zero and no payload is actually copied to the monitor interface, leaving data un-initialized.
Fix this by removing the linear vs non-linear split and using skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as vhost-vsock already does. This handles both linear and non-linear skbs, properly initializes the iov_iter, and removes the now unused virtio_transport_copy_nonlinear_skb().
While touching this code, let's also check the return value of skb_copy_datagram_iter(), even though it's unlikely to fail.
{
"affected": [],
"aliases": [
"CVE-2026-46207"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: fix empty payload in tap skb for non-linear buffers\n\nFor non-linear skbs, virtio_transport_build_skb() goes through\nvirtio_transport_copy_nonlinear_skb() to copy the original payload\nin the new skb to be delivered to the vsockmon tap device.\nThis manually initializes an iov_iter but does not set iov_iter.count.\nSince the iov_iter is zero-initialized, the copy length is zero and no\npayload is actually copied to the monitor interface, leaving data\nun-initialized.\n\nFix this by removing the linear vs non-linear split and using\nskb_copy_datagram_iter() with iov_iter_kvec() for all cases, as\nvhost-vsock already does. This handles both linear and non-linear skbs,\nproperly initializes the iov_iter, and removes the now unused\nvirtio_transport_copy_nonlinear_skb().\n\nWhile touching this code, let\u0027s also check the return value of\nskb_copy_datagram_iter(), even though it\u0027s unlikely to fail.",
"id": "GHSA-c7cv-93jx-fc79",
"modified": "2026-06-10T21:31:25Z",
"published": "2026-05-28T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06747f52ab157591cec7e5623a759473b66ef6f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/378b131a25bd1a5ee27ca199fe486c299d5350c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a3e3d90cbc79600544536723911657730759af3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52da6a74ca3de0fcda60301096b71534b3b18641"
}
],
"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-C7JW-QWF7-GQXX
Vulnerability from github – Published: 2022-05-13 01:13 – Updated: 2022-05-13 01:13A memory leak was discovered in the backport of fixes for CVE-2018-16864 in Red Hat Enterprise Linux. Function dispatch_message_real() in journald-server.c does not free the memory allocated by set_iovec_field_free() to store the _CMDLINE= entry. A local attacker may use this flaw to make systemd-journald crash. This issue only affects versions shipped with Red Hat Enterprise since v219-62.2.
{
"affected": [],
"aliases": [
"CVE-2019-3815"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-28T15:29:00Z",
"severity": "LOW"
},
"details": "A memory leak was discovered in the backport of fixes for CVE-2018-16864 in Red Hat Enterprise Linux. Function dispatch_message_real() in journald-server.c does not free the memory allocated by set_iovec_field_free() to store the `_CMDLINE=` entry. A local attacker may use this flaw to make systemd-journald crash. This issue only affects versions shipped with Red Hat Enterprise since v219-62.2.",
"id": "GHSA-c7jw-qwf7-gqxx",
"modified": "2022-05-13T01:13:35Z",
"published": "2022-05-13T01:13:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3815"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2019:0327"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:0201"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2019-3815"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1666690"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3815"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/03/msg00013.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106632"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
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.