CWE-415
AllowedDouble Free
Abstraction: Variant · Status: Draft
The product calls free() twice on the same memory address.
1091 vulnerabilities reference this CWE, most recent first.
GHSA-7VW9-HMX7-H29G
Vulnerability from github – Published: 2025-04-17 21:30 – Updated: 2025-04-17 21:30In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix potential double free in create_var_ref()
In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function.
Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref().
{
"affected": [],
"aliases": [
"CVE-2022-49410"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:17Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix potential double free in create_var_ref()\n\nIn create_var_ref(), init_var_ref() is called to initialize the fields\nof variable ref_field, which is allocated in the previous function call\nto create_hist_field(). Function init_var_ref() allocates the\ncorresponding fields such as ref_field-\u003esystem, but frees these fields\nwhen the function encounters an error. The caller later calls\ndestroy_hist_field() to conduct error handling, which frees the fields\nand the variable itself. This results in double free of the fields which\nare already freed in the previous function.\n\nFix this by storing NULL to the corresponding fields when they are freed\nin init_var_ref().",
"id": "GHSA-7vw9-hmx7-h29g",
"modified": "2025-04-17T21:30:44Z",
"published": "2025-04-17T21:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49410"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/058cb6d86b9789377216c936506b346aaa1eb581"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7W6V-JHVX-QX5C
Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2024-12-20 18:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix double free of anonymous device after snapshot creation failure
When creating a snapshot we may do a double free of an anonymous device in case there's an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem.
The steps that lead to this:
1) At ioctl.c:create_snapshot() we allocate an anonymous device number and assign it to pending_snapshot->anon_dev;
2) Then we call btrfs_commit_transaction() and end up at transaction.c:create_pending_snapshot();
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device number stored in pending_snapshot->anon_dev;
4) btrfs_get_new_fs_root() frees that anonymous device number because btrfs_lookup_fs_root() returned a root - someone else did a lookup of the new root already, which could some task doing backref walking;
5) After that some error happens in the transaction commit path, and at ioctl.c:create_snapshot() we jump to the 'fail' label, and after that we free again the same anonymous device number, which in the meanwhile may have been reallocated somewhere else, because pending_snapshot->anon_dev still has the same value as in step 1.
Recently syzbot ran into this and reported the following trace:
------------[ cut here ]------------ ida_free called for id=51 which is not allocated. WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Modules linked in: CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Code: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Call Trace: btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Code: 28 00 00 00 (...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658
Where we get an explicit message where we attempt to free an anonymous device number that is not currently allocated. It happens in a different code path from the example below, at btrfs_get_root_ref(), so this change may not fix the case triggered by sy ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26792"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T09:15:08Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix double free of anonymous device after snapshot creation failure\n\nWhen creating a snapshot we may do a double free of an anonymous device\nin case there\u0027s an error committing the transaction. The second free may\nresult in freeing an anonymous device number that was allocated by some\nother subsystem in the kernel or another btrfs filesystem.\n\nThe steps that lead to this:\n\n1) At ioctl.c:create_snapshot() we allocate an anonymous device number\n and assign it to pending_snapshot-\u003eanon_dev;\n\n2) Then we call btrfs_commit_transaction() and end up at\n transaction.c:create_pending_snapshot();\n\n3) There we call btrfs_get_new_fs_root() and pass it the anonymous device\n number stored in pending_snapshot-\u003eanon_dev;\n\n4) btrfs_get_new_fs_root() frees that anonymous device number because\n btrfs_lookup_fs_root() returned a root - someone else did a lookup\n of the new root already, which could some task doing backref walking;\n\n5) After that some error happens in the transaction commit path, and at\n ioctl.c:create_snapshot() we jump to the \u0027fail\u0027 label, and after\n that we free again the same anonymous device number, which in the\n meanwhile may have been reallocated somewhere else, because\n pending_snapshot-\u003eanon_dev still has the same value as in step 1.\n\nRecently syzbot ran into this and reported the following trace:\n\n ------------[ cut here ]------------\n ida_free called for id=51 which is not allocated.\n WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525\n Modules linked in:\n CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\n RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525\n Code: 10 42 80 3c 28 (...)\n RSP: 0018:ffffc90015a67300 EFLAGS: 00010246\n RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000\n RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000\n RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4\n R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246\n R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246\n FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0\n Call Trace:\n \u003cTASK\u003e\n btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346\n create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837\n create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931\n btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404\n create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848\n btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998\n btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044\n __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306\n btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393\n btrfs_ioctl+0xa74/0xd40\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:871 [inline]\n __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n RIP: 0033:0x7fca3e67dda9\n Code: 28 00 00 00 (...)\n RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9\n RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003\n RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658\n \u003c/TASK\u003e\n\nWhere we get an explicit message where we attempt to free an anonymous\ndevice number that is not currently allocated. It happens in a different\ncode path from the example below, at btrfs_get_root_ref(), so this change\nmay not fix the case triggered by sy\n---truncated---",
"id": "GHSA-7w6v-jhvx-qx5c",
"modified": "2024-12-20T18:31:29Z",
"published": "2024-04-04T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26792"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c34adc20b91a8e55e048b18d63f4f4ae003ecf8f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8ab7521665bd0f8bc4a900244d1d5a7095cc3b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2b54eaf28df0c978626c9736b94f003b523b451"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb3441093aad251418921246fc3b224fd1575701"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7WW5-CHP8-5MWJ
Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2026-06-15 12:32In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: Fix use after free in atomisp_alloc_css_stat_bufs()
The "s3a_buf" is freed along with all the other items on the "asd->s3a_stats" list. It leads to a double free and a use after free.
{
"affected": [],
"aliases": [
"CVE-2020-36785"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:36Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: atomisp: Fix use after free in atomisp_alloc_css_stat_bufs()\n\nThe \"s3a_buf\" is freed along with all the other items on the\n\"asd-\u003es3a_stats\" list. It leads to a double free and a use after free.",
"id": "GHSA-7ww5-chp8-5mwj",
"modified": "2026-06-15T12:32:44Z",
"published": "2024-02-28T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36785"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/801c1d505894008c888bc71d08d5cff5d87f8aba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8267ccd7b9df7ab682043507dd682fe0621cf045"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba11bbf303fafb33989e95473e409f6ab412b18d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d218c7a0284f6b92a7b82d2e19706e18663b4193"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7WX7-289W-5FPM
Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-11 18:31Windows Resilient File System (ReFS) Deduplication Service Elevation of Privilege Vulnerability
{
"affected": [],
"aliases": [
"CVE-2025-21182"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-11T18:15:29Z",
"severity": "HIGH"
},
"details": "Windows Resilient File System (ReFS) Deduplication Service Elevation of Privilege Vulnerability",
"id": "GHSA-7wx7-289w-5fpm",
"modified": "2025-02-11T18:31:36Z",
"published": "2025-02-11T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21182"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21182"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7X73-763J-HW4V
Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2026-02-20 21:31A remote code execution vulnerability exists when the Windows font library improperly handles specially crafted embedded fonts, aka 'Microsoft Graphics Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2019-1145, CVE-2019-1149, CVE-2019-1150, CVE-2019-1151, CVE-2019-1152.
{
"affected": [],
"aliases": [
"CVE-2019-1144"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-14T21:15:00Z",
"severity": "HIGH"
},
"details": "A remote code execution vulnerability exists when the Windows font library improperly handles specially crafted embedded fonts, aka \u0027Microsoft Graphics Remote Code Execution Vulnerability\u0027. This CVE ID is unique from CVE-2019-1145, CVE-2019-1149, CVE-2019-1150, CVE-2019-1151, CVE-2019-1152.",
"id": "GHSA-7x73-763j-hw4v",
"modified": "2026-02-20T21:31:09Z",
"published": "2022-05-24T16:53:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1144"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1144"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/154085/Microsoft-Font-Subsetting-DLL-MergeFormat12Cmap-MakeFormat12MergedGlyphList-Double-Free.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7XF4-2CCH-Q53V
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a potential double-free in fs_any_create_groups
When kcalloc() for ft->g succeeds but kvzalloc() for in fails, fs_any_create_groups() will free ft->g. However, its caller fs_any_create_table() will free ft->g again through calling mlx5e_destroy_flow_table(), which will lead to a double-free. Fix this by setting ft->g to NULL in fs_any_create_groups().
{
"affected": [],
"aliases": [
"CVE-2023-52667"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:09Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: fix a potential double-free in fs_any_create_groups\n\nWhen kcalloc() for ft-\u003eg succeeds but kvzalloc() for in fails,\nfs_any_create_groups() will free ft-\u003eg. However, its caller\nfs_any_create_table() will free ft-\u003eg again through calling\nmlx5e_destroy_flow_table(), which will lead to a double-free.\nFix this by setting ft-\u003eg to NULL in fs_any_create_groups().",
"id": "GHSA-7xf4-2cch-q53v",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52667"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-825R-GH5G-48MG
Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2025-01-14 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix memory double free when handle zero packet
829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again.
Log:
[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]
Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.
{
"affected": [],
"aliases": [
"CVE-2024-26748"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T17:15:51Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829 if (request-\u003ecomplete) {\n830 spin_unlock(\u0026priv_dev-\u003elock);\n831 usb_gadget_giveback_request(\u0026priv_ep-\u003eendpoint,\n832 request);\n833 spin_lock(\u0026priv_dev-\u003elock);\n834 }\n835\n836 if (request-\u003ebuf == priv_dev-\u003ezlp_buf)\n837 cdns3_gadget_ep_free_request(\u0026priv_ep-\u003eendpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][ T150]\n[ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn\u0027t call\nusb_gadget_giveback_request() because it is allocated in this driver.",
"id": "GHSA-825r-gh5g-48mg",
"modified": "2025-01-14T18:31:49Z",
"published": "2024-04-03T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26748"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8295-HCJH-5W9P
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix potential bit_17 double-free
A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock.
[tursulin: Correct fixes tag and added cc stable.] (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e)
{
"affected": [],
"aliases": [
"CVE-2023-52930"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:42Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix potential bit_17 double-free\n\nA userspace with multiple threads racing I915_GEM_SET_TILING to set the\ntiling to I915_TILING_NONE could trigger a double free of the bit_17\nbitmask. (Or conversely leak memory on the transition to tiled.) Move\nallocation/free\u0027ing of the bitmask within the section protected by the\nobj lock.\n\n[tursulin: Correct fixes tag and added cc stable.]\n(cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e)",
"id": "GHSA-8295-hcjh-5w9p",
"modified": "2025-04-15T18:31:41Z",
"published": "2025-03-27T18:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52930"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0769f997a7b6d5cb8336db0b4ec3d2d311b8097c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7057a8f126f14f14b040faecfa220fd27c6c2f85"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b591abac78e25269b12e3d7170c99463f8c5cb02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3ebc3e23bd9028a8a9a26cbc5985f99be445f65"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-82J6-3C7M-V8GC
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46A double free condition can occur when the device moves to suspend mode during secure playback in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile
{
"affected": [],
"aliases": [
"CVE-2020-11246"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-07T08:15:00Z",
"severity": "HIGH"
},
"details": "A double free condition can occur when the device moves to suspend mode during secure playback in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile",
"id": "GHSA-82j6-3c7m-v8gc",
"modified": "2022-05-24T17:46:43Z",
"published": "2022-05-24T17:46:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11246"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/april-2021-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-82V4-79HW-3G4G
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-11 03:30In the Linux kernel, the following vulnerability has been resolved:
mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock
damon_sysfs_quot_goal->path can be read and written by users, via DAMON sysfs 'path' file. It can also be indirectly read, for the parameters {on,off}line committing to DAMON. The reads for parameters committing are protected by damon_sysfs_lock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the path-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damon_sysfs_lock.
{
"affected": [],
"aliases": [
"CVE-2026-46183"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:33Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock\n\ndamon_sysfs_quot_goal-\u003epath can be read and written by users, via DAMON\nsysfs \u0027path\u0027 file. It can also be indirectly read, for the parameters\n{on,off}line committing to DAMON. The reads for parameters committing are\nprotected by damon_sysfs_lock to avoid the sysfs files being destroyed\nwhile any of the parameters are being read. But the user-driven direct\nreads and writes are not protected by any lock, while the write is\ndeallocating the path-pointing buffer. As a result, the readers could\nread the already freed buffer (user-after-free). Note that the user-reads\ndon\u0027t race when the same open file is used by the writer, due to kernfs\u0027s\nopen file locking. Nonetheless, doing the reads and writes with separate\nopen files would be common. Fix it by protecting both the user-direct\nreads and writes with damon_sysfs_lock.",
"id": "GHSA-82v4-79hw-3g4g",
"modified": "2026-06-11T03:30:23Z",
"published": "2026-05-28T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46183"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a34ca3e33da4b924c66bcca3729bf68ec5936910"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf3b71421ca00807328c6d9cd242f9de3b77a4bf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Choose a language that provides automatic memory management.
Mitigation
Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.
Mitigation
Use a static analysis tool to find double free instances.
No CAPEC attack patterns related to this CWE.