clock_time_get rejects valid WASI pointer arguments >= 0x80000000(2G)

Version

v24.14.1

Platform

Darwin XQ4PWYXX93 24.6.0 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:55 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6031 arm64

Subsystem

wasi

What steps will reproduce the bug?

Run this with node repro.mjs(or run node reproduce.mjs in
https://github.com/hardfist/node-wasi-2gb-bug and this is the cause of Rspack CI failure https://github.com/web-infra-dev/rspack/actions/runs/24226483089/job/70729993137?pr=13655#step:13:104

import { WASI } from 'node:wasi';

const wasm = Buffer.from(
  'AGFzbQEAAAABDwNgA39+fwF/YAABf2AAAAIpARZ3YXNpX3NuYXBzaG90X3ByZXZpZXcxDmNsb2NrX3RpbWVfZ2V0AAADBQQBAQECBQUBAIGAAgdHBQZtZW1vcnkCAA50ZXN0X2Nsb2NrX2xvdwABDnRlc3RfY2xvY2tfbWlkAAIPdGVzdF9jbG9ja19oaWdoAAMGX3N0YXJ0AAQKMwQMAEEAQsCEPUEAEAALEABBAELAhD1B8P///wcQAAsQAEEAQsCEPUGAgICAeBAACwIACw==',
  'base64',
);

const wasi = new WASI({ version: 'preview1' });
const module = await WebAssembly.compile(wasm);
const instance = await WebAssembly.instantiate(module, {
  wasi_snapshot_preview1: wasi.wasiImport,
});

try {
  wasi.start(instance);
} catch {}

for (const [label, fn] of [
  ['0x00000000', () => instance.exports.test_clock_low()],
  ['0x7FFFFFF0', () => instance.exports.test_clock_mid()],
  ['0x80000000', () => instance.exports.test_clock_high()],
]) {
  const errno = fn();
  console.log(`${label}: errno=${errno}`);
}

This embeds a tiny WASM module that:

• imports wasi_snapshot_preview1.clock_time_get
• allocates 32769 pages of memory (2GB + 64KB)
• calls clock_time_get with result pointers 0x00000000, 0x7FFFFFF0, and 0x80000000

How often does it reproduce? Is there a required condition?

It reproduces every time for me on v24.14.1 when the WASI function receives an i32 argument with the high bit set, such as pointer 0x80000000, and the module has enough linear memory for that offset. The repro needs about 2GB of free RAM because the module allocates 32769 pages.

What is the expected behavior? Why is that the expected behavior?

All three calls should succeed:

0x00000000: errno=0
0x7FFFFFF0: errno=0
0x80000000: errno=0

0x80000000 is a valid in-bounds offset for a 32769-page memory, and WASI pointer parameters are 32-bit offsets. Node should accept the full 32-bit bit-pattern range for these arguments and then rely on the existing memory bounds checks to reject only truly out-of-bounds accesses.

What do you see instead?

The third call returns EINVAL (28) even though the pointer is within bounds:

0x00000000: errno=0
0x7FFFFFF0: errno=0
0x80000000: errno=28

Additional information

I traced this to the WASI slow callback path in src/node_wasi.cc.

CheckType<uint32_t>() currently does:

template <>
bool CheckType<uint32_t>(Local<Value> value) {
  return value->IsUint32();
}

But when Wasm passes i32.const 0x80000000, V8 appears to surface that value to the JS-facing slow callback as the Number -2147483648. That fails IsUint32(), so SlowCallback() returns UVWASI_EINVAL before the syscall implementation runs.

ConvertType<uint32_t>() in the same file already does:

template <>
uint32_t ConvertType(Local<Value> value) {
  return value.As<Uint32>()->Value();
}

So this looks like a validation mismatch rather than a conversion or bounds-checking issue. If I am reading the code correctly, CheckType<uint32_t>() probably needs to accept the signed JS representation that Wasm i32 values can take when the high bit is set, or otherwise validate these parameters in a way that is not sensitive to JS signedness.

Comienza en src/node_wasi.cc, centrándote en CheckType<uint32_t>(), ConvertType<uint32_t>() y la ruta lenta de callback descrita en el issue. Ejecuta la reproducción de WebAssembly proporcionada y compara el comportamiento para los tres valores de puntero; se considera terminado cuando la llamada dentro de los límites con 0x80000000 devuelve errno 0, mientras que los punteros realmente inválidos siguen siendo rechazados.