[BUG] BigInt memory leak in Atomics.store on detached SharedArrayBuffer
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- c, javascript
- Domain
- security
Research direction
Start in quickjs.c at js_atomics_store(), tracing JS_ToBigInt64() through the detached-buffer check in js_atomics_get_ptr(). Reproduce the reported tight loop with a detached BigInt64Array; done when repeated failing Atomics.store calls no longer retain BigInt allocations while still returning the expected error.
Written by the indexing model from the issue text.
Description
Summary
js_atomics_store() in quickjs.c leaks BigInt memory when writing to a BigInt64Array or BigUint64Array backed by a detached SharedArrayBuffer. The function converts the value argument to a BigInt (allocating heap memory) before checking whether the underlying buffer is still valid. When the buffer is detached, the function returns an error but never frees the BigInt.
Root Cause
if (class_id == JS_CLASS_BIG_INT64_ARRAY ||
class_id == JS_CLASS_BIG_UINT64_ARRAY) {
int64_t v64;
if (JS_ToBigInt64(ctx, &v64, val)) // <-- allocates BigInt on heap
return JS_EXCEPTION;
// ... later:
if (js_atomics_get_ptr(...) == NULL) // <-- detached buffer check
return JS_EXCEPTION; // <-- BigInt never freed
The BigInt allocated by JS_ToBigInt64() is not freed on the detached-buffer error path. Each call leaks the BigInt allocation (typically 32+ bytes). In a tight loop, this exhausts available memory.
Impact
Memory leak via crafted JavaScript. An attacker-controlled script can exhaust process memory by repeatedly calling Atomics.store() on a detached BigInt64Array in a loop. This is a denial-of-service condition.
CWE-401, CVSS 5.3
- Dominant language
- C
- Stars
- 11k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bellard/quickjs
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 3/5 1-2 days Newbie friendliness 50/100
-
Difficulty 4/5 3-5 days Newbie friendliness 65/100
-
Difficulty 3/5 1-2 days Newbie friendliness 70/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Similar issues
-
level/task module/gcp type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
docs
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
P3 sonic-vpp
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sonic-net/sonic-buildimage#29662 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 94/100
spack/spack-packages#6586 ·
-
category:port-update
Difficulty 2/5 1-3 hours Newbie friendliness 72/100