Fix integer overflow in Chakra napi_create_dataview bounds check

[bkaradzic-microsoft]

Summary

napi_create_dataview (Chakra backend) validated the requested view with an unchecked byte_length + byte_offset > bufferLength comparison. Both operands are caller-supplied size_t values, so on 64-bit builds their sum can overflow and wrap past the limit. When that happens:

• the values are truncated to 32-bit for JsCreateDataView (yielding a small, valid view), but
• the original 64-bit byte_offset/byte_length are stored in DataViewInfo and later returned by napi_get_dataview_info alongside the small backing buffer

…handing a calling native addon an out-of-bounds read/write primitive (CWE-190 → CWE-125/787, also CWE-681).

Fix

Validate byte_offset and byte_length against the buffer size individually, without adding them:
cpp if (byte_offset > bufferLength || byte_length > bufferLength - byte_offset) { /* range error */ }
After this check both values are <= bufferLength (a 32-bit quantity), so the later 32-bit truncation and the values stored in DataViewInfo are guaranteed in range.

• JavaScriptCore backend delegates to the JS DataView constructor → unaffected.
• V8 backend carries the same upstream pattern but is vendored verbatim from Node → left untouched.

Test

This path is not reachable from JS (new DataView uses the engine directly, not this N-API), so coverage is a native gtest. It crafts an offset/length whose low 32 bits are valid for a 16-byte buffer but whose 64-bit sum wraps, and asserts the view is rejected (and never reports the raw 64-bit extents). Guarded to the Chakra engine and 64-bit builds (JSRUNTIMEHOST_NAPI_ENGINE_CHAKRA + _WIN64).

Verified the test fails on the pre-fix code and passes after the fix; full suite green (5 native tests + 151 JS tests) on Win32-x64 Chakra Debug.

[Copilot]

Pull request overview

This pull request hardens the Chakra Node-API implementation of napi_create_dataview against a size_t addition overflow in its bounds check, preventing creation of a DataView whose stored (reported) offset/length could be out of range for the underlying buffer (potential OOB access in native addons). It also adds a targeted native regression test and wires up a build define so the test only compiles/runs for the Chakra configuration.

Changes:

• Fix overflow-prone range validation in napi_create_dataview by checking byte_offset and byte_length against the buffer size without adding them.
• Add a Chakra + 64-bit guarded gtest regression that reproduces the wraparound scenario and asserts the request is rejected (or at minimum never reports raw huge extents).
• Add a CMake compile definition (JSRUNTIMEHOST_NAPI_ENGINE_CHAKRA) for UnitTests when building with the Chakra backend.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
Core/Node-API/Source/js_native_api_chakra.cc	Replaces the overflow-prone byte_length + byte_offset bounds check with a subtraction-based check that cannot overflow and keeps stored DataViewInfo extents in range.
Tests/UnitTests/Shared/Shared.cpp	Adds a Chakra/_WIN64 regression test that constructs an overflowing (offset, length) pair and verifies it is rejected (and does not leak huge extents via napi_get_dataview_info).
Tests/UnitTests/CMakeLists.txt	Defines JSRUNTIMEHOST_NAPI_ENGINE_CHAKRA for UnitTests when NAPI_JAVASCRIPT_ENGINE is Chakra, enabling the guarded regression test.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

Fix LGTM; comments inline.

[bghgary]

Drop this guard. The test's assertions are backend-agnostic (overflow rejected, or reported extents in range), so it should run on V8/JSC too and verify they reject the overflow instead of assuming it. The guard also only exists by adding the JSRUNTIMEHOST_NAPI_ENGINE_CHAKRA compile-def in CMakeLists, which is otherwise unused — so this forces a CMake change for no real reason.

[bkaradzic-microsoft]

Done — removed the JSRUNTIMEHOST_NAPI_ENGINE_CHAKRA guard. The test is backend-agnostic (it asserts the overflow is either rejected or reported in range), so it now runs on V8/JSC too and verifies they reject it. Confirmed it still passes on Chakra locally.

[bghgary]

This compile-def exists only to drive the Chakra #ifdef around the new test. With that guard removed, nothing else uses it — drop this block too.

[bkaradzic-microsoft]

Done — dropped this block; with the #ifdef removed, nothing else used JSRUNTIMEHOST_NAPI_ENGINE_CHAKRA.

[bghgary]

_WIN64 is MSVC/Windows-only, not a portable 64-bit check. The precondition is a 64-bit size_t, and <cstdint> is already included:

Suggested change

	#ifdef _WIN64
	#if SIZE_MAX > 0xFFFFFFFFu

Leave this as the sole guard — it also works on the non-Windows backends the test should now run on.

[bkaradzic-microsoft]

Done — replaced _WIN64 with #if SIZE_MAX > 0xFFFFFFFFu as the sole guard (<cstdint> is already included), so it's a portable 64-bit size_t check that also covers the non-Windows backends.