Skip to content

Fix: Module loading panics on non-UTF-8 file paths#6460

Open
jedisct1 wants to merge 4 commits intowasmerio:mainfrom
dip-proto:non-utf8-module-path-panics
Open

Fix: Module loading panics on non-UTF-8 file paths#6460
jedisct1 wants to merge 4 commits intowasmerio:mainfrom
dip-proto:non-utf8-module-path-panics

Conversation

@jedisct1
Copy link
Copy Markdown

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

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
@jedisct1 jedisct1 requested a review from syrusakbary as a code owner April 12, 2026 17:34
Copilot AI review requested due to automatic review settings April 12, 2026 17:34
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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() with to_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.

jedisct1 and others added 3 commits April 12, 2026 20:17
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants