CWE-415
AllowedDouble Free
Abstraction: Variant · Status: Draft
The product calls free() twice on the same memory address.
1001 vulnerabilities reference this CWE, most recent first.
GHSA-XH5P-RM5R-7F82
Vulnerability from github – Published: 2025-05-13 00:31 – Updated: 2025-11-03 21:33A double free issue was addressed with improved memory management. This issue is fixed in iPadOS 17.7.7, macOS Ventura 13.7.6, macOS Sequoia 15.5, macOS Sonoma 14.7.6. An app may be able to cause unexpected system termination.
{
"affected": [],
"aliases": [
"CVE-2025-31235"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-12T22:15:23Z",
"severity": "MODERATE"
},
"details": "A double free issue was addressed with improved memory management. This issue is fixed in iPadOS 17.7.7, macOS Ventura 13.7.6, macOS Sequoia 15.5, macOS Sonoma 14.7.6. An app may be able to cause unexpected system termination.",
"id": "GHSA-xh5p-rm5r-7f82",
"modified": "2025-11-03T21:33:53Z",
"published": "2025-05-13T00:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31235"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122405"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122716"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122717"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122718"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/May/6"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/May/7"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/May/8"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/May/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XHJP-R5QG-3389
Vulnerability from github – Published: 2026-07-24 18:31 – Updated: 2026-07-27 06:30In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: avoid double free of pool->stack on AQ init failure
otx2_pool_aq_init() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2_sq_aura_pool_init() unwinds the partial setup through otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific cn20k_pool_aq_init() implementation has the same bug in its corresponding error path.
Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.
Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware.
{
"affected": [],
"aliases": [
"CVE-2026-64222"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-24T16:16:50Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: avoid double free of pool-\u003estack on AQ init failure\n\notx2_pool_aq_init() frees pool-\u003estack when mailbox sync or retry\nallocation fails, but leaves the pointer unchanged. Later,\notx2_sq_aura_pool_init() unwinds the partial setup through\notx2_aura_pool_free(), which frees pool-\u003estack again. The CN20K-specific\ncn20k_pool_aq_init() implementation has the same bug in\nits corresponding error path.\n\nSet pool-\u003estack to NULL immediately after the local free so the shared\ncleanup path does not free the same stack again while cleaning up\npartially initialized pool state.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still present in\nv7.1-rc3.\n\nRuntime validation was not performed because reproducing this path\nrequires OcteonTX2/CN20K hardware.",
"id": "GHSA-xhjp-r5qg-3389",
"modified": "2026-07-27T06:30:30Z",
"published": "2026-07-24T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64222"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0488a0bb344fb1992853b60082acff6be8164d74"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d9b9d7dbef976ae7f855b6358f1d703014e96ea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c29603498b05c049dbbbc47e882f2fbf0193cd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94192b0579333c3deee2441379aab8ca98fc2e6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b244c242bec48b37e82b89787afd6a4c43457e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b92e7ea408b6f1144648909c9c49a55d245d7300"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c4b8c5d51632538b19ee01cf6d70cbceeefbd3ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6e9bc0bf963662b7042048ab0281014625d4cb4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XHM7-3CGH-G3G7
Vulnerability from github – Published: 2022-05-14 01:29 – Updated: 2022-05-14 01:29Double-free vulnerability in libavformat/mov.c in FFMPEG in Google Chrome 41.0.2251.0 allows remote attackers to cause a denial of service (memory corruption and crash) via a crafted .m4a file.
{
"affected": [],
"aliases": [
"CVE-2015-1207"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-06T18:29:00Z",
"severity": "MODERATE"
},
"details": "Double-free vulnerability in libavformat/mov.c in FFMPEG in Google Chrome 41.0.2251.0 allows remote attackers to cause a denial of service (memory corruption and crash) via a crafted .m4a file.",
"id": "GHSA-xhm7-3cgh-g3g7",
"modified": "2022-05-14T01:29:12Z",
"published": "2022-05-14T01:29:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1207"
},
{
"type": "WEB",
"url": "https://bugs.chromium.org/p/chromium/issues/detail?id=444539"
},
{
"type": "WEB",
"url": "https://gist.github.com/bittorrent3389/8fee7cdaa73d1d351ee9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/02/msg00005.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XJFC-F2RJ-H2HM
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-27 15:30In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: only publish mode_data after clone setup
iptfs_clone_state() stores x->mode_data before allocating the reorder window. If that allocation fails, the code frees the cloned state and returns -ENOMEM, leaving x->mode_data pointing at freed memory.
The xfrm clone unwind later runs destroy_state() through x->mode_data, so the failed clone path tears down IPTFS state that clone_state() already freed.
Keep the cloned IPTFS state private until all allocations succeed so failed clones leave x->mode_data unset. The destroy path already handles a NULL mode_data pointer.
{
"affected": [],
"aliases": [
"CVE-2026-31471"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:43Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: iptfs: only publish mode_data after clone setup\n\niptfs_clone_state() stores x-\u003emode_data before allocating the reorder\nwindow. If that allocation fails, the code frees the cloned state and\nreturns -ENOMEM, leaving x-\u003emode_data pointing at freed memory.\n\nThe xfrm clone unwind later runs destroy_state() through x-\u003emode_data,\nso the failed clone path tears down IPTFS state that clone_state()\nalready freed.\n\nKeep the cloned IPTFS state private until all allocations succeed so\nfailed clones leave x-\u003emode_data unset. The destroy path already\nhandles a NULL mode_data pointer.",
"id": "GHSA-xjfc-f2rj-h2hm",
"modified": "2026-04-27T15:30:38Z",
"published": "2026-04-22T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31471"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/371a43c4ac70cac0de9f9b1fc5b1660b9565b9f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5784a1e2889c9525a8f036cb586930e232170bf7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d849a2f7309fc0616e79d13b008b0a47e0458b6e"
}
],
"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-XJV4-5HJM-MW83
Vulnerability from github – Published: 2022-01-14 00:02 – Updated: 2023-05-27 06:30The binary MP4Box in Gpac 1.0.1 has a double-free vulnerability in the ilst_box_read function in box_code_apple.c, which allows attackers to cause a denial of service, even code execution and escalation of privileges.
{
"affected": [],
"aliases": [
"CVE-2021-40571"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-13T18:15:00Z",
"severity": "HIGH"
},
"details": "The binary MP4Box in Gpac 1.0.1 has a double-free vulnerability in the ilst_box_read function in box_code_apple.c, which allows attackers to cause a denial of service, even code execution and escalation of privileges.",
"id": "GHSA-xjv4-5hjm-mw83",
"modified": "2023-05-27T06:30:38Z",
"published": "2022-01-14T00:02:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40571"
},
{
"type": "WEB",
"url": "https://github.com/gpac/gpac/issues/1895"
},
{
"type": "WEB",
"url": "https://github.com/gpac/gpac/commit/a69b567b8c95c72f9560c873c5ab348be058f340"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5411"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XM3X-2CX4-FH5J
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36In DrmManagerService::~DrmManagerService() of DrmManagerService.cpp, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-155647761
{
"affected": [],
"aliases": [
"CVE-2020-0483"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-15T16:15:00Z",
"severity": "MODERATE"
},
"details": "In DrmManagerService::~DrmManagerService() of DrmManagerService.cpp, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-155647761",
"id": "GHSA-xm3x-2cx4-fh5j",
"modified": "2022-05-24T17:36:26Z",
"published": "2022-05-24T17:36:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0483"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2020-12-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XP2H-P3FR-J2J5
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-16 21:30In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix double SIGFPE crash
Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.
When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.
The issue can be reproduced with this test program:
root@parisc:~# cat fpe.c
static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }
int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }
root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception
root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 / 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception
{
"affected": [],
"aliases": [
"CVE-2025-37991"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T18:15:45Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0027s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026set);\n sigaddset(\u0026set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026set, NULL);\n printf(\"GOT signal %d with si_code %ld\\n\", sig, i-\u003esi_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\"%lf\\n\",1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\"./a.out\", [\"./a.out\"], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception",
"id": "GHSA-xp2h-p3fr-j2j5",
"modified": "2025-12-16T21:30:49Z",
"published": "2025-05-20T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37991"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.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-XP4F-MW6J-JXM8
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-12 18:30Double free in Windows Rich Text Edit allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-21530"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T18:16:38Z",
"severity": "MODERATE"
},
"details": "Double free in Windows Rich Text Edit allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-xp4f-mw6j-jxm8",
"modified": "2026-05-12T18:30:40Z",
"published": "2026-05-12T18:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21530"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21530"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XP4H-Q65R-X2PM
Vulnerability from github – Published: 2024-12-04 12:31 – Updated: 2024-12-04 12:31Double-Free Vulnerability in uD3TN BPv7 Caused by Malformed Endpoint Identifier allows remote attacker to reliably cause DoS
{
"affected": [],
"aliases": [
"CVE-2024-12107"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-04T11:15:05Z",
"severity": "HIGH"
},
"details": "Double-Free Vulnerability in uD3TN BPv7 Caused by Malformed Endpoint Identifier allows remote attacker to reliably cause DoS",
"id": "GHSA-xp4h-q65r-x2pm",
"modified": "2024-12-04T12:31:45Z",
"published": "2024-12-04T12:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12107"
},
{
"type": "WEB",
"url": "https://gitlab.com/d3tn/ud3tn/-/issues/233"
}
],
"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-XPHW-CQX3-667J
Vulnerability from github – Published: 2026-04-15 19:24 – Updated: 2026-05-05 15:43Summary
A Double Free / Use-After-Free (UAF) vulnerability has been identified in the IntoIter::drop and ThinVec::clear implementations of the thin_vec crate.
Both vulnerabilities share the same root cause and can trigger memory corruption using only safe Rust code — no unsafe blocks required.
Undefined Behavior has been confirmed via Miri and AddressSanitizer (ASAN).
Details
Both vulnerabilities share the same root cause. When a panic occurs during sequential element deallocation, the subsequent length cleanup code (set_len(0)) is never executed. During stack unwinding, the container is dropped again, causing already-freed memory to be re-freed (Double Free / UAF).
Vulnerability 1 — IntoIter::drop
Location: thin-vec/src/lib.rs L.2308~2314
IntoIter::drop transfers ownership of the internal buffer via mem::replace, then sequentially frees elements via ptr::drop_in_place.
If a panic occurs during element deallocation, set_len_non_singleton(0) is never reached. During unwinding, vec is dropped again, re-freeing already-freed elements.
The standard library's std::vec::IntoIter prevents this with a DropGuard pattern, but thin-vec lacks this defense.
// Problematic structure (conceptual representation)
impl<T> Drop for IntoIter<T> {
fn drop(&mut self) {
let mut vec = mem::replace(&mut self.vec, ThinVec::new());
unsafe {
ptr::drop_in_place(vec.remaining_slice_mut()); // ← panic may occur here
vec.set_len_non_singleton(0); // ← unreachable on panic
}
// During unwinding, vec is dropped again → Double Free
}
}
Vulnerability 2 — ThinVec::clear
clear() calls ptr::drop_in_place(&mut self[..]) followed by self.set_len(0) to reset the length.
If a panic occurs during element deallocation, set_len(0) is never executed. When the ThinVec itself is subsequently dropped, already-freed elements are freed again.
// Problematic structure (conceptual representation)
pub fn clear(&mut self) {
unsafe {
ptr::drop_in_place(&mut self[..]); // ← panic may occur here
self.set_len(0); // ← unreachable on panic
}
// ThinVec drop later → Double Free
}
Recommended Fix
Both vulnerabilities can be resolved with the same pattern:
- DropGuard pattern: Insert an RAII guard before
drop_in_placeto guaranteeset_len(0)is called regardless of panic - Pre-zeroing approach: Set the length to 0 before calling
drop_in_place
PoC
Requirements: Rust nightly toolchain, thin-vec = "0.2.14"
# Miri
cargo +nightly miri run
# ASAN
RUSTFLAGS="-Z sanitizer=address" cargo +nightly run --release
PoC-1: IntoIter::drop
use thin_vec::ThinVec;
struct PanicBomb(String);
impl Drop for PanicBomb {
fn drop(&mut self) {
if self.0 == "panic" {
panic!("panic!");
}
println!("Dropping: {}", self.0);
}
}
fn main() {
let mut v = ThinVec::new();
v.push(PanicBomb(String::from("normal1")));
v.push(PanicBomb(String::from("panic"))); // trigger element
v.push(PanicBomb(String::from("normal2")));
let mut iter = v.into_iter();
iter.next();
// When iter is dropped: panic occurs at "panic" element
// → During unwinding, Double Drop is triggered on "normal1" (already freed)
}
Miri output:
error: Undefined Behavior: pointer not dereferenceable:
alloc227 has been freed, so this pointer is dangling
stack backtrace:
3: <PanicBomb as Drop>::drop ← Double Drop entry
6: <ThinVec<T> as Drop>::drop::drop_non_singleton
9: <IntoIter<T> as Drop>::drop::drop_non_singleton ← lib.rs:2310 (root cause)
ASAN output:
==66150==ERROR: AddressSanitizer: heap-use-after-free on address 0x7afa685e0010
READ of size 7 at 0x7afa685e0010
#0 memcpy
#4 drop_in_place::<PanicBomb> ← Double Drop entry point
#5 <ThinVec as Drop>::drop::drop_non_singleton
#6 <IntoIter as Drop>::drop::drop_non_singleton
PoC-2: ThinVec::clear
use thin_vec::ThinVec;
use std::panic;
struct Poison(Box<usize>, &'static str);
impl Drop for Poison {
fn drop(&mut self) {
if self.1 == "panic" {
panic!("panic!");
}
println!("Dropping: {}", self.0);
}
}
fn main() {
let mut v = ThinVec::new();
v.push(Poison(Box::new(1), "normal1")); // index 0
v.push(Poison(Box::new(2), "panic")); // index 1 → panic triggered here
v.push(Poison(Box::new(3), "normal2")); // index 2
let _ = panic::catch_unwind(panic::AssertUnwindSafe(|| {
v.clear();
// panic occurs at "panic" element during clear()
// → set_len(0) is never called
// → already-freed elements are re-freed when v goes out of scope
}));
}
Impact
Vulnerability classification: - CWE-415: Double Free - CWE-416: Use-After-Free
Affected code: All code satisfying the following conditions simultaneously:
ThinVecstores heap-owning types (String,Vec,Box, etc.)- (Vulnerability 1) An iterator is created via
into_iter()and dropped before being fully consumed, or (Vulnerability 2)clear()is called while a remaining element'sDropimplementation can panic - The
Dropimplementation of a remaining element triggers a panic
Additionally, when combined with Box<dyn Trait> types, an exploit primitive enabling Arbitrary Code Execution (ACE) via heap spray and vtable hijacking has been confirmed. If the freed fat pointer slot (16 bytes) at the point of Double Drop is reclaimed by an attacker-controlled fake vtable, subsequent Drop calls can be redirected to attacker-controlled code.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "thin-vec"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-6654"
],
"database_specific": {
"cwe_ids": [
"CWE-415",
"CWE-416"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-15T19:24:54Z",
"nvd_published_at": "2026-04-20T11:16:19Z",
"severity": "HIGH"
},
"details": "### Summary\n\nA **Double Free / Use-After-Free (UAF)** vulnerability has been identified in the `IntoIter::drop` and `ThinVec::clear` implementations of the `thin_vec` crate.\nBoth vulnerabilities share the same root cause and can trigger memory corruption using only safe Rust code \u2014 no `unsafe` blocks required.\nUndefined Behavior has been confirmed via **Miri** and **AddressSanitizer (ASAN)**.\n\n---\n\n### Details\n\nBoth vulnerabilities share the same root cause. When a **panic occurs** during sequential element deallocation, the subsequent length cleanup code (`set_len(0)`) is never executed. During stack unwinding, the container is dropped again, causing already-freed memory to be re-freed (Double Free / UAF).\n\n#### Vulnerability 1 \u2014 `IntoIter::drop`\n\n**Location:** `thin-vec/src/lib.rs` L.2308~2314\n\n`IntoIter::drop` transfers ownership of the internal buffer via `mem::replace`, then sequentially frees elements via `ptr::drop_in_place`.\nIf a panic occurs during element deallocation, `set_len_non_singleton(0)` is never reached. During unwinding, `vec` is dropped again, re-freeing already-freed elements.\nThe standard library\u0027s `std::vec::IntoIter` prevents this with a **DropGuard pattern**, but thin-vec lacks this defense.\n\n```rust\n// Problematic structure (conceptual representation)\nimpl\u003cT\u003e Drop for IntoIter\u003cT\u003e {\n fn drop(\u0026mut self) {\n let mut vec = mem::replace(\u0026mut self.vec, ThinVec::new());\n unsafe {\n ptr::drop_in_place(vec.remaining_slice_mut()); // \u2190 panic may occur here\n vec.set_len_non_singleton(0); // \u2190 unreachable on panic\n }\n // During unwinding, vec is dropped again \u2192 Double Free\n }\n}\n```\n\n#### Vulnerability 2 \u2014 `ThinVec::clear`\n\n`clear()` calls `ptr::drop_in_place(\u0026mut self[..])` followed by `self.set_len(0)` to reset the length.\nIf a panic occurs during element deallocation, `set_len(0)` is never executed. When the `ThinVec` itself is subsequently dropped, already-freed elements are freed again.\n\n```rust\n// Problematic structure (conceptual representation)\npub fn clear(\u0026mut self) {\n unsafe {\n ptr::drop_in_place(\u0026mut self[..]); // \u2190 panic may occur here\n self.set_len(0); // \u2190 unreachable on panic\n }\n // ThinVec drop later \u2192 Double Free\n}\n```\n\n#### Recommended Fix\n\nBoth vulnerabilities can be resolved with the same pattern:\n\n- **DropGuard pattern:** Insert an RAII guard before `drop_in_place` to guarantee `set_len(0)` is called regardless of panic\n- **Pre-zeroing approach:** Set the length to 0 before calling `drop_in_place`\n\n---\n\n### PoC\n\n**Requirements:** Rust nightly toolchain, `thin-vec = \"0.2.14\"`\n\n```bash\n# Miri\ncargo +nightly miri run\n\n# ASAN\nRUSTFLAGS=\"-Z sanitizer=address\" cargo +nightly run --release\n```\n\n#### PoC-1: `IntoIter::drop`\n\n```rust\nuse thin_vec::ThinVec;\n\nstruct PanicBomb(String);\n\nimpl Drop for PanicBomb {\n fn drop(\u0026mut self) {\n if self.0 == \"panic\" {\n panic!(\"panic!\");\n }\n println!(\"Dropping: {}\", self.0);\n }\n}\n\nfn main() {\n let mut v = ThinVec::new();\n v.push(PanicBomb(String::from(\"normal1\")));\n v.push(PanicBomb(String::from(\"panic\"))); // trigger element\n v.push(PanicBomb(String::from(\"normal2\")));\n\n let mut iter = v.into_iter();\n iter.next();\n // When iter is dropped: panic occurs at \"panic\" element\n // \u2192 During unwinding, Double Drop is triggered on \"normal1\" (already freed)\n}\n```\n\n**Miri output:**\n```\nerror: Undefined Behavior: pointer not dereferenceable:\n alloc227 has been freed, so this pointer is dangling\n\nstack backtrace:\n 3: \u003cPanicBomb as Drop\u003e::drop \u2190 Double Drop entry\n 6: \u003cThinVec\u003cT\u003e as Drop\u003e::drop::drop_non_singleton\n 9: \u003cIntoIter\u003cT\u003e as Drop\u003e::drop::drop_non_singleton \u2190 lib.rs:2310 (root cause)\n```\n\n**ASAN output:**\n```\n==66150==ERROR: AddressSanitizer: heap-use-after-free on address 0x7afa685e0010\nREAD of size 7 at 0x7afa685e0010\n #0 memcpy\n #4 drop_in_place::\u003cPanicBomb\u003e \u2190 Double Drop entry point\n #5 \u003cThinVec as Drop\u003e::drop::drop_non_singleton\n #6 \u003cIntoIter as Drop\u003e::drop::drop_non_singleton\n```\n\n#### PoC-2: `ThinVec::clear`\n\n```rust\nuse thin_vec::ThinVec;\nuse std::panic;\n\nstruct Poison(Box\u003cusize\u003e, \u0026\u0027static str);\n\nimpl Drop for Poison {\n fn drop(\u0026mut self) {\n if self.1 == \"panic\" {\n panic!(\"panic!\");\n }\n println!(\"Dropping: {}\", self.0);\n }\n}\n\nfn main() {\n let mut v = ThinVec::new();\n v.push(Poison(Box::new(1), \"normal1\")); // index 0\n v.push(Poison(Box::new(2), \"panic\")); // index 1 \u2192 panic triggered here\n v.push(Poison(Box::new(3), \"normal2\")); // index 2\n\n let _ = panic::catch_unwind(panic::AssertUnwindSafe(|| {\n v.clear();\n // panic occurs at \"panic\" element during clear()\n // \u2192 set_len(0) is never called\n // \u2192 already-freed elements are re-freed when v goes out of scope\n }));\n}\n```\n\n---\n\n### Impact\n\n**Vulnerability classification:**\n- CWE-415: Double Free\n- CWE-416: Use-After-Free\n\n**Affected code:** All code satisfying the following conditions simultaneously:\n\n1. `ThinVec` stores heap-owning types (`String`, `Vec`, `Box`, etc.)\n2. (Vulnerability 1) An iterator is created via `into_iter()` and dropped before being fully consumed, or\n (Vulnerability 2) `clear()` is called while a remaining element\u0027s `Drop` implementation can panic\n3. The `Drop` implementation of a remaining element triggers a panic\n\nAdditionally, when combined with `Box\u003cdyn Trait\u003e` types, an exploit primitive enabling Arbitrary Code Execution (ACE) via heap spray and vtable hijacking has been confirmed. If the freed fat pointer slot (16 bytes) at the point of Double Drop is reclaimed by an attacker-controlled fake vtable, subsequent Drop calls can be redirected to attacker-controlled code.",
"id": "GHSA-xphw-cqx3-667j",
"modified": "2026-05-05T15:43:14Z",
"published": "2026-04-15T19:24:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mozilla/thin-vec/security/advisories/GHSA-xphw-cqx3-667j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6654"
},
{
"type": "PACKAGE",
"url": "https://github.com/mozilla/thin-vec"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0103.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "thin-vec: Use-After-Free and Double Free in IntoIter::drop When Element Drop Panics"
}
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.