[SECURITY] Panic-safety vulnerabilities in heapless v0.9.2 with demonstrated arbitrary code execution
Summary
I have identified four panic-safety vulnerabilities in heapless v0.9.2 affecting core container operations. Through security research, I have developed proof-of-concept demonstrations showing that two of these vulnerabilities can be exploited for arbitrary code execution.
Technical Assessment:
- Affected APIs: 4 container operations
- Severity: High to Critical (CVSS 7.8-8.5 range)
- Attack Vector: Local execution via safe Rust code
- Demonstrated Impact: Arbitrary code execution capability
Affected APIs
HistoryBuf::write() - Single metadata update vulnerabilityVec::IntoIter::drop() - Single metadata update vulnerabilityHistoryBufInner::clear() - Multiple metadata update vulnerability (ACE demonstrated)DequeInner::clear() - Multiple metadata update vulnerability (ACE demonstrated)
Disclosure Background
I am disclosing this issue publicly as I received guidance to proceed with a public issue.
Technical Findings
Vulnerability Pattern
All four issues share a common root cause where container metadata updates occur after element destruction rather than before:
// Vulnerable pattern
unsafe { ptr::drop_in_place(...) }; // Panic here leaves container inconsistent
self.metadata = safe_value; // Never reachedWhen an element's Drop implementation panics, containers remain in inconsistent states, leading to:
- Use-after-free conditions during subsequent operations
- Double-free scenarios with heap-allocated element types
- Memory corruption exploitable through controlled heap manipulation
Arbitrary Code Execution Capability
I have successfully developed working demonstrations for the clear() method vulnerabilities that achieve arbitrary code execution through vtable hijacking.
Exploitation technique:
- Storing trait objects with controlled vtable pointers
- Triggering panic conditions during element destruction
- Using heap spraying to reclaim freed memory locations
- Hijacking vtable calls to redirect execution flow
Working proof-of-concept code is available for private review if a security advisory process is established.
Security Advisory Request
I would respectfully request consideration of creating a GitHub Security Advisory (GHSA) for these findings.
The most significant aspect of these discoveries is that actual arbitrary code execution capability has been demonstrated. Beyond simple memory safety issues, I have confirmed the reliability of vtable hijacking techniques through proof-of-concept that achieves shell execution. Such practical attack scenarios could pose serious security risks, particularly in embedded and systems programming environments.
The Rust ecosystem has established precedent for handling panic-safety vulnerabilities with demonstrated exploitation potential through coordinated security advisory processes. Most notably, CVE-2026-6654 (thin-vec) addressed the identical panic-safety → ACE pattern, confirming that this class of vulnerability warrants formal security advisory treatment when arbitrary code execution is demonstrated.
Given the demonstrated arbitrary code execution capability and the established precedent for handling similar panic-safety issues, I believe these findings would benefit from the same coordinated security process to ensure proper vulnerability tracking and ecosystem notification.
Thank you for maintaining heapless and for considering appropriate security processes for these findings.
[SECURITY] Panic-safety vulnerabilities in heapless v0.9.2 with demonstrated arbitrary code execution
Summary
I have identified four panic-safety vulnerabilities in heapless v0.9.2 affecting core container operations. Through security research, I have developed proof-of-concept demonstrations showing that two of these vulnerabilities can be exploited for arbitrary code execution.
Technical Assessment:
Affected APIs
HistoryBuf::write()- Single metadata update vulnerabilityVec::IntoIter::drop()- Single metadata update vulnerabilityHistoryBufInner::clear()- Multiple metadata update vulnerability (ACE demonstrated)DequeInner::clear()- Multiple metadata update vulnerability (ACE demonstrated)Disclosure Background
I am disclosing this issue publicly as I received guidance to proceed with a public issue.
Technical Findings
Vulnerability Pattern
All four issues share a common root cause where container metadata updates occur after element destruction rather than before:
When an element's
Dropimplementation panics, containers remain in inconsistent states, leading to:Arbitrary Code Execution Capability
I have successfully developed working demonstrations for the
clear()method vulnerabilities that achieve arbitrary code execution through vtable hijacking.Exploitation technique:
Working proof-of-concept code is available for private review if a security advisory process is established.
Security Advisory Request
I would respectfully request consideration of creating a GitHub Security Advisory (GHSA) for these findings.
The most significant aspect of these discoveries is that actual arbitrary code execution capability has been demonstrated. Beyond simple memory safety issues, I have confirmed the reliability of vtable hijacking techniques through proof-of-concept that achieves shell execution. Such practical attack scenarios could pose serious security risks, particularly in embedded and systems programming environments.
The Rust ecosystem has established precedent for handling panic-safety vulnerabilities with demonstrated exploitation potential through coordinated security advisory processes. Most notably, CVE-2026-6654 (thin-vec) addressed the identical panic-safety → ACE pattern, confirming that this class of vulnerability warrants formal security advisory treatment when arbitrary code execution is demonstrated.
Given the demonstrated arbitrary code execution capability and the established precedent for handling similar panic-safety issues, I believe these findings would benefit from the same coordinated security process to ensure proper vulnerability tracking and ecosystem notification.
Thank you for maintaining heapless and for considering appropriate security processes for these findings.