Is it a security vulnerability?
No, the bug does not result in a crash or hang, only a silent failure.
Describe the bug
On platforms without a hardware random source (e.g. NuttX on RP2350/rp23xx), every WASI file descriptor allocation fails silently because fd_table_unused() has no fallback when random_uniform() cannot obtain entropy.
The WASM module receives an unexpected WASI error code on any open() or socket() call. There is no indication at any layer that the root cause is the absence of an entropy source, the error surfaces as an unrelated filesystem or socket error.
Currently, the chain is:
posix.c: fd_table_unused() -> calls random_uniform()
random.c: random_uniform() -> calls random_buf()
random.c: random_buf() -> calls getrandom(buf, len, 0)
random.c: -> getrandom() returns -1, errno=ENOENT (no RNG driver registered in OS)
random.c: -> convert_errno(ENOENT) = __WASI_ENOENT (44)
posix.c: fd_table_unused() -> returns error, fd allocation fails
Version
WAMR 2.4.4
To Reproduce
Steps to reproduce the behavior:
- Compile iwasm for NuttX on RP2350 (rp23XX ARM) with INTERPRETERS_WAMR_LIBC_WASI enabled and no RNG driver registered.
- Run a WASM module that calls open() or any socket function, for example the [https://github.com/bytecodealliance/wasm-micro-runtime/blob/5aebe728bd67a5e3ae1779f31a74539ba7fc0736/samples/socket-api/wasm-src/tcp_server.c#L4](TCP Server from Socket API sample).
- See the given error.
Expected behavior
When no random source is available, fd_table_unused() should find an alternative, for example: falling back to a sequential scan of the fd table and successfully allocate a file descriptor. Note that a sequential fallback is not random and may be considered insecure in contexts where fd number unpredictability matters, however it is preferable to a silent failure that renders WASI file and socket operations completely unusable. At the very least it should specify the error to the user instead of surfacing as an unrelated WASI error code.
Actual Result
With the udp_server from the sample:
psock_fstat: WARNING: Socket not connected //nuttx message
Create socket failed: No such file or directory // wamr error
ERRNO: 44
Environment:
- Arch: ARM (32-bit)
- Board: Raspberry Pi RP2350 (rp23xx)
- OS: NuttX
- Version: WAMR 2.4.4
Additional context
Root cause is in
core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/posix.c, fd_table_unused()
Proposed fix: when random_uniform() returns an error indicating the random source is unavailable (__WASI_ENOENT, __WASI_ENOSYS, __WASI_ENOTSUP), fall back to a sequential scan of ft->entries[] for the first slot where object == NULL. If the sequential fallback is considered too insecure, random_buf() should at
least emit a specific error before returning, so the root cause is visible:
if (x < 0) {
if (errno == EINTR)
continue;
printf("[random_buf] getrandom() failed: errno=%d — "
"no entropy source available, fd allocation will fail\n", errno);
return convert_errno(errno);
}
Currently the error surfaces as an unrelated WASI errno (ENOENT/ENOSYS) on open() or socket() with no indication that the root cause is a missing RNG driver. This makes the bug extremely difficult to diagnose.
Is it a security vulnerability?
No, the bug does not result in a crash or hang, only a silent failure.
Describe the bug
On platforms without a hardware random source (e.g. NuttX on RP2350/rp23xx), every WASI file descriptor allocation fails silently because
fd_table_unused()has no fallback whenrandom_uniform()cannot obtain entropy.The WASM module receives an unexpected WASI error code on any
open()orsocket()call. There is no indication at any layer that the root cause is the absence of an entropy source, the error surfaces as an unrelated filesystem or socket error.Currently, the chain is:
posix.c: fd_table_unused() -> calls random_uniform()
random.c: random_uniform() -> calls random_buf()
random.c: random_buf() -> calls getrandom(buf, len, 0)
random.c: -> getrandom() returns -1, errno=ENOENT (no RNG driver registered in OS)
random.c: -> convert_errno(ENOENT) = __WASI_ENOENT (44)
posix.c: fd_table_unused() -> returns error, fd allocation fails
Version
WAMR 2.4.4
To Reproduce
Steps to reproduce the behavior:
Expected behavior
When no random source is available,
fd_table_unused()should find an alternative, for example: falling back to a sequential scan of the fd table and successfully allocate a file descriptor. Note that a sequential fallback is not random and may be considered insecure in contexts where fd number unpredictability matters, however it is preferable to a silent failure that renders WASI file and socket operations completely unusable. At the very least it should specify the error to the user instead of surfacing as an unrelated WASI error code.Actual Result
With the udp_server from the sample:
Environment:
Additional context
Root cause is in
core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/posix.c,
fd_table_unused()Proposed fix: when
random_uniform()returns an error indicating the random source is unavailable (__WASI_ENOENT, __WASI_ENOSYS, __WASI_ENOTSUP), fall back to a sequential scan offt->entries[]for the first slot whereobject == NULL. If the sequential fallback is considered too insecure,random_buf()should atleast emit a specific error before returning, so the root cause is visible:
Currently the error surfaces as an unrelated WASI errno (ENOENT/ENOSYS) on open() or socket() with no indication that the root cause is a missing RNG driver. This makes the bug extremely difficult to diagnose.