Repository navigation
[wasi] FileStream_ctor_sfh_fa_buffer.InconsistentFileAccessThrows corrupts memory (interpreter and ReadyToRun) #134957
Description
Activity
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.- added a commit that references this issue
on Sep 30, 2026 Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.- added a commit that references this issue
on Sep 30, 2026 Update: this still reproduces on current main (a1cdbbb), which includes the recent wasm GC reporting fixes (#134779). It is not specific to ReadyToRun.
Configuration (System.IO.FileSystem.DisabledFileLocking.Tests) Result Interpreter wasm trap: out of bounds memory accessincorerun!pread←SystemNative_PRead←InvokeUnmanagedCalli←InterpExecMethod. WithXunitShowProgress, the last started test isFileStream_ctor_sfh_fa_buffer.InconsistentFileAccessThrows.Trimmed ReadyToRun The xunit runner dies with ArgumentNullException (Parameter 'source')inTestClassRunner.RunAsync, then anunreachabletrap inSfiNextWorkerduring exception dispatch.Trimmed ReadyToRun, this test skipped 1103 run, 0 failed The test reads through a write-only handle and writes through a read-only handle and expects
UnauthorizedAccessException. The interpreter failure is inpreadfor the failing read, which suggests the failed read/write path on WASI hands native code a bad buffer pointer or length. The original R2R GC-time fault address0x800560a0(in 128 MB of linear memory) looks like the same kind of invalid pointer. GC slot reporting is probably a symptom rather than the cause. A root-cause investigation is in progress.On #134813 the quarantine now covers all WASI configurations.
Note
This comment was drafted with the help of GitHub Copilot.
- changed the title
[-][wasi][R2R] GC stack scan reports an invalid untracked slot from ReadyToRun code[/-][+][wasi] FileStream_ctor_sfh_fa_buffer.InconsistentFileAccessThrows corrupts memory (interpreter and ReadyToRun)[/+]on Sep 30, 2026 Root cause
This isn't a GC-reporting or R2R bug. It's a wasi-libc bug in the wasip2
preadshipped with wasi-sdk 33, which this repo builds with.preadconsumes thedescriptor.readresult before checking whether the call failed (pread.catwasi-sdk-33):bool ok = filesystem_method_descriptor_read(file_handle, nbyte, offset, &contents, &error_code); bytes_read = contents.f0.len; // uninitialized on failure memcpy(buf, contents.f0.ptr, bytes_read); // garbage src pointer and length wasip2_list_u8_free(&contents.f0); // free() of a garbage pointer if (!ok) { ... return -1; }
On failure the binding never writes
contents, sopreadcopies a stale-stack-sized chunk from a stale-stack pointer into the caller's buffer, then frees a stale pointer. Depending on what's on the stack, that traps immediately (the interpreter'sout of bounds memory accessincorerun!pread) or silently corrupts the heap or managed objects. The corruption case explains the ReadyToRun symptoms: a GC-time memory fault at a garbage address, orArgumentNullExceptionin the xunit runner followed by anunreachabletrap during exception dispatch.InconsistentFileAccessThrowstriggers it by opening the fileFileAccess.Write, wrapping the handle asFileAccess.Read, and callingReadByte(). That goesRandomAccess.ReadAtOffset→SystemNative_PRead→preadon a write-only fd,descriptor.readfails withbad-descriptor, and the bad copy and free follow. Browser passes because emscripten'spreaddoesn't have this bug.Upstream fixed it in WebAssembly/wasi-libc#862 (issue WebAssembly/wasi-libc#861), first released in wasi-sdk 34.
Evidence
- A 20-line C program built with the repo's wasi-sdk 33 (
--target=wasm32-wasip2) that callspreadon anO_WRONLYfd traps with the sameout of bounds memory accessinpread. - On current main (
137a6701515), interpreter,-class System.IO.Tests.FileStream_ctor_sfh_fa_buffer:- Unmodified: traps at
corerun!pread <- SystemNative_PRead. - With a guard in
SystemNative_PRead:Tests run: 10 Passed: 10 Failed: 0.
- Unmodified: traps at
- With the guard, the full
System.IO.FileSystem.DisabledFileLocking.Testssuite runs to completion (1517 tests, no trap). All threeInconsistentFileAccessThrowsvariants pass. The remaining failures are unrelated WASI gaps: PNSE from APM/threading and pipe conformance tests.
Fix
- Workaround, draft PR [wasi] Avoid wasi-libc pread memory corruption on write-only descriptors #134988: on
TARGET_WASI,SystemNative_PReadand thePReadVfallback reject fds that aren't open for reading (fcntl(F_GETFL)) withEBADFbefore callingpread.EBADFis what the fixed libc returns, and it maps to theUnauthorizedAccessExceptionthe test expects. - Real fix: move to wasi-sdk 34. That also covers other
descriptor.readfailures, such as I/O errors, that the guard doesn't. The workaround has aTODO-WASIpointing here so it can be removed after the bump.
I moved the label from
area-CodeGen-coreclrtoarea-System.IO, since the runtime-side change is in System.Native'spal_io.c.Note
This comment was generated with GitHub Copilot.
- A 20-line C program built with the repo's wasi-sdk 33 (
Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.- added 13 commits that reference this issue
on Oct 1, 2026
Description
With CoreCLR WASI ReadyToRun, System.IO.FileSystem.DisabledFileLocking.Tests crashes during a garbage collection while running
System.IO.Tests.FileStream_ctor_sfh_fa_buffer.InconsistentFileAccessThrows. The GC's stack scan reports a slot through the wasm32 GC info that does not hold a valid object reference, and marking it reads outside linear memory:The collection is triggered by a large object allocation. The untracked slot comes from a ReadyToRun-compiled frame on the stack. The wasmtime backtrace is truncated at 20 frames, so the method with the bad GC info is not identified yet. Rerun with a deeper backtrace or under a debugger to find the frame, then compare its GC info with the slots the compiled code actually initializes.
This may be the same root cause as #134947, an out-of-bounds access that also appears only with ReadyToRun.
Seen in trimmed ReadyToRun runs of the CoreCLR WASI library tests for #134813.
Note
This issue was drafted with the help of GitHub Copilot.