Buffer Overflow in bigint-buffer’s toBigIntLE() leads to DoS in @solana/spl-token

[muse0509]

Description:
Versions ≤1.1.5 of the [bigint-buffer](https://github.com/no2chem/bigint-buffer) package contain a buffer-overflow bug in the native toBigIntLE() binding. Because @solana/spl-token (via buffer-layout-utils) uses toBigIntLE() to deserialize token amounts, passing an invalid or non-Buffer argument can crash the Node.js process, resulting in a denial-of-service.

Steps to Reproduce:

1. Install a vulnerable setup:

   npm install @solana/spl-token@0.4.13 bigint-buffer@1.1.5

2. In Node.js (with native-bindings enabled), call for example:

   const { toBigIntLE } = require('bigint-buffer');
   toBigIntLE(null);  // invalid input

3. Observe the process crash with a segmentation fault or native addon error.

Actual Behavior:
Node.js process terminates unexpectedly due to a native buffer-overflow in toBigIntLE().

Expected Behavior:
Invalid inputs should throw a JavaScript-level TypeError (or similar) without crashing the process.

Environment:

• Node.js v16+ (with node-gyp build tooling)
• @solana/spl-token v0.4.13 (via @solana/buffer-layout-utils)
• bigint-buffer v1.1.5

Impact:
High severity (CVE-2025-3194 / GHSA-3gc7-fjrx-p6mg). An attacker controlling buffer-input data can trigger a DoS by crashing any service deserializing SPL Token amounts.

Suggested Mitigation:

1. Add a guard in toBigIntLE() (native addon) to validate Buffer.isBuffer(input) before dereferencing.
2. Fallback to the pure-JS implementation on invalid input rather than invoking the native binding.
3. Release patched versions of bigint-buffer, and bump @solana/web3.js / @solana/spl-token to depend on the fixed version.

References:

• GitHub Advisory: GHSA-3gc7-fjrx-p6mg
• CVE-2025-3194: https://nvd.nist.gov/vuln/detail/CVE-2025-3194
• Snyk Report: https://security.snyk.io/vuln/SNYK-JS-BIGINTBUFFER-3364597

Labels:
area/security severity/high needs-triage

---

[BuberryWorldwide]

Proposed Fix Available

I've created a fix that replaces the vulnerable bigint-buffer package with pure JavaScript implementations.

PR with the fix: https://github.com/BuberryWorldwide/buffer-layout-utils/pull/new/fix/remove-bigint-buffer-vulnerability

Since solana-labs/buffer-layout-utils is now archived, this would need to either:

1. Fork and publish a patched version of @solana/buffer-layout-utils
2. Vendor the fix directly into @solana/spl-token
3. Unarchive buffer-layout-utils temporarily to merge the fix

The Fix

Replace bigint-buffer imports with pure JS implementations:

```typescript
function toBigIntLE(buffer: Buffer): bigint {
if (buffer.length === 0) return 0n;
let result = 0n;
for (let i = buffer.length - 1; i >= 0; i--) {
result = (result << 8n) + BigInt(buffer[i]);
}
return result;
}

function toBufferLE(value: bigint, length: number): Buffer {
const buffer = Buffer.alloc(length);
let remaining = value;
for (let i = 0; i < length; i++) {
buffer[i] = Number(remaining & 0xffn);
remaining = remaining >> 8n;
}
return buffer;
}
```

These implementations:

• Are functionally equivalent to bigint-buffer
• Have no native dependencies
• Are safe from buffer overflow
• Have been tested with values from 0 to max u256

Impact

This vulnerability has been open for 8+ months and affects thousands of projects. The bigint-buffer package is abandoned (last commit: January 2023), so waiting for an upstream fix is not viable.

Happy to help get this merged however works best for the Solana team.

[stevenclawd-pixel]

Analysis

I read the @solana/buffer-layout-utils source (v0.3.0) to understand the actual exposure.

The decode path in bigint.js:

bigIntLayout.decode = (buffer, offset) => {
    const src = decode(buffer, offset);
    return littleEndian
        ? toBigIntLE(Buffer.from(src))  // Buffer.from wraps src first
        : toBigIntBE(Buffer.from(src));
};

The library already wraps src in Buffer.from() before passing to the native binding. This provides partial protection — for most invalid inputs, Buffer.from() will throw at the JS level before reaching the native code.

Where real exposure remains:

1. bigint-buffer v1.1.5 is the latest published version and has not been patched — no upgrade path exists at the dependency level
2. If decode(buffer, offset) (from @solana/buffer-layout) returns a Uint8Array-like with unexpected underlying memory, Buffer.from() may not copy safely in all runtimes — this is a runtime-specific risk
3. The encode path has assertValidBigInteger() guarding it, but the decode path has no corresponding guard

Proposed fix (JS-level, no native changes needed):

Add a size + type assertion in the decode path inside buffer-layout-utils:

bigIntLayout.decode = (buffer, offset) => {
    const src = decode(buffer, offset);
    // Guard: ensure src is a valid fixed-length buffer before passing to native binding
    if (!Buffer.isBuffer(src) && !ArrayBuffer.isView(src)) {
        throw new TypeError(`Expected a Buffer or TypedArray, got ${typeof src}`);
    }
    if (src.length !== length) {
        throw new RangeError(`Expected ${length} bytes, got ${src.length}`);
    }
    const safeSrc = Buffer.from(src);
    return littleEndian ? toBigIntLE(safeSrc) : toBigIntBE(safeSrc);
};

This validates both the type and the length before the native binding is invoked, eliminating the crash path from malformed account data.

I can submit a PR to @solana/buffer-layout-utils with this guard if the maintainers think it's the right place for it. The alternative is to vendor a pure-JS bigint implementation and remove the native dependency entirely, which would be safer long-term but a larger change.