Skip to content

Security: Potential Memory Safety Issue in ArrayBuffer JSI Converter#360

Open
tomaioo wants to merge 1 commit into
wcandillon:mainfrom
tomaioo:fix/security/potential-memory-safety-issue-in-arraybu
Open

Security: Potential Memory Safety Issue in ArrayBuffer JSI Converter#360
tomaioo wants to merge 1 commit into
wcandillon:mainfrom
tomaioo:fix/security/potential-memory-safety-issue-in-arraybu

Conversation

@tomaioo
Copy link
Copy Markdown

@tomaioo tomaioo commented May 20, 2026

Summary

Security: Potential Memory Safety Issue in ArrayBuffer JSI Converter

Problem

Severity: High | File: packages/webgpu/cpp/rnwgpu/ArrayBuffer.h:L65

In ArrayBuffer.h, the createArrayBufferFromJSI function creates an shared_ptr that wraps raw pointers obtained from JSI ArrayBuffer objects. The byteOffset and byteLength values are cast from asNumber() without bounds checking against the actual ArrayBuffer size. A malicious or malformed JSI object could provide values that cause out-of-bounds memory access. Additionally, the bytesPerElements value is used without validation, which could lead to incorrect memory calculations.

Solution

Add strict bounds checking to ensure byteOffset + byteLength does not exceed the underlying ArrayBuffer size. Validate bytesPerElements is a positive integer within expected ranges. Consider using span or similar bounded view types instead of raw pointers.

Changes

  • packages/webgpu/cpp/rnwgpu/ArrayBuffer.h (modified)

In `ArrayBuffer.h`, the `createArrayBufferFromJSI` function creates an shared_ptr<ArrayBuffer> that wraps raw pointers obtained from JSI ArrayBuffer objects. The `byteOffset` and `byteLength` values are cast from `asNumber()` without bounds checking against the actual ArrayBuffer size. A malicious or malformed JSI object could provide values that cause out-of-bounds memory access. Additionally, the `bytesPerElements` value is used without validation, which could lead to incorrect memory calculations.

Signed-off-by: tomaioo <203048277+tomaioo@users.noreply.github.com>
Copy link
Copy Markdown
Owner

@wcandillon wcandillon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to had a test there?

obj.getProperty(runtime, "byteOffset").asNumber());
auto byteLength = static_cast<size_t>(
obj.getProperty(runtime, "byteLength").asNumber());
if (bytesPerElements <= 0 || bytesPerElements > 8) {
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we guard here, should we also guard that this is an integer value?

@tomaioo
Copy link
Copy Markdown
Author

tomaioo commented May 21, 2026

Yes, we should validate that byteOffset, byteLength, and bytesPerElement are all integer values before the bounds check. Non-integer values from JSI could cause truncation issues or unexpected behavior in memory calculations. I'll add std::isfinite() and std::floor() == value checks, or use JSI's integer conversion if available, alongside the bounds validation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants