Fix: Module loading panics on non-UTF-8 file paths#6460
Open
jedisct1 wants to merge 4 commits intowasmerio:mainfrom
Open
Fix: Module loading panics on non-UTF-8 file paths#6460jedisct1 wants to merge 4 commits intowasmerio:mainfrom
jedisct1 wants to merge 4 commits intowasmerio:mainfrom
Conversation
SUMMARY Loading a module from an existing file whose canonical path is not valid UTF-8 panics instead of returning an `IoCompileError`. PROVENANCE This exploration and report were automatically generated by the Swival Security Scanner (https://swival.dev). PRECONDITIONS - `BackendModule::from_file()` is called with a path that exists and can be read. - The canonicalized filesystem path contains non-UTF-8 bytes, which is allowed on Unix filesystems. PROOF 1. Input/source/state origin: `BackendModule::from_file()` accepts an arbitrary `impl AsRef<Path>` in `lib/api/src/entities/module/inner.rs:73-76`. 2. Control-flow and data-flow path: it canonicalizes the path, reads the file, creates the module, then converts the canonical path with `canonical.as_path().to_str().unwrap()` in `lib/api/src/entities/module/inner.rs:78-84`. 3. Failing condition or violated invariant: `Path::to_str()` returns `None` for valid non-UTF-8 Unix paths, and `unwrap()` panics instead of propagating an error. 4. Resulting impact: the embedding process aborts while loading a valid file path, violating the function’s `Result<_, IoCompileError>` contract. 5. Why this is reachable in the current code: no earlier step rejects non-UTF-8 paths; canonicalization and file reading both operate on `Path`, not UTF-8 strings. WHY THIS IS A REAL BUG This is a concrete filesystem-boundary bug, not a style issue: valid inputs cause a panic in a function that advertises recoverable error handling. PATCH RATIONALE The patch uses `to_string_lossy()` for the debug name instead of `unwrap()`. That preserves existing naming behavior for UTF-8 paths and avoids crashing on valid non-UTF-8 paths without changing module loading semantics. RESIDUAL RISK None
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Fixes a panic when module loading encounters a valid but non-UTF-8 canonical filesystem path by avoiding unwrap() during path-to-string conversion.
Changes:
- Replace
Path::to_str().unwrap()withto_string_lossy()when setting a module’s debug name. - Keep module-loading semantics the same while preventing process aborts on Unix non-UTF-8 paths.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* main: fix(wasix): Make connect nonblocking when requested and implement real socket::status Go from UnionFS to MountFS, which properly supports nested mounts and eliminate mounting from all other filesystems (wasmerio#6391) deps(LLVM): bump to 22.1 (wasmerio#6300) fix(deps): Update rand to fix RUSTSEC-2026-0097 (wasmerio#6456)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SUMMARY
Loading a module from an existing file whose canonical path is not valid UTF-8 panics instead of returning an
IoCompileError.PROVENANCE
This exploration and report were automatically generated by the Swival Security Scanner (https://swival.dev).
PRECONDITIONS
BackendModule::from_file()is called with a path that exists and can be read.PROOF
BackendModule::from_file()accepts an arbitraryimpl AsRef<Path>inlib/api/src/entities/module/inner.rs:73-76.canonical.as_path().to_str().unwrap()inlib/api/src/entities/module/inner.rs:78-84.Path::to_str()returnsNonefor valid non-UTF-8 Unix paths, andunwrap()panics instead of propagating an error.Result<_, IoCompileError>contract.Path, not UTF-8 strings.WHY THIS IS A REAL BUG
This is a concrete filesystem-boundary bug, not a style issue: valid inputs cause a panic in a function that advertises recoverable error handling.
PATCH RATIONALE
The patch uses
to_string_lossy()for the debug name instead ofunwrap(). That preserves existing naming behavior for UTF-8 paths and avoids crashing on valid non-UTF-8 paths without changing module loading semantics.RESIDUAL RISK
None