wasi: do not panic on extreme file timestamps in DescriptorStat - #13894
Merged
alexcrichton merged 7 commits intoJul 20, 2026
Merged
Conversation
Datetime::try_from can fail when SystemTime is outside the i64-second range. datetime_from used unwrap(), so a guest that set extreme timestamps on a preopened path could crash the host on the next stat. Map conversion failure to a missing timestamp (Option::None) instead. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
alexcrichton
left a comment
alexcrichton
left a comment
Member
There was a problem hiding this comment.
Thanks for the PR, but please be sure you review our AI tool usage policy. You own the code and you own the responsibility for being correct here, and for example the analysis of when this was introduced was wrong. The PR referred there was a refactor and did not introduce this.
Inline try_from mapping, drop narrative comments, and keep a small unit test under mod test for SystemTime values outside Datetime's range. Guest set_times cannot construct those values because they already use Datetime; host Metadata is the overflow path. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Contributor
Author
Thanks for the review. I re-read the AI tool use policy and corrected the PR description: #13872 was a refactor of the conversion site, not the introduction of this failure mode. Sorry for the incorrect origin claim. Addressed the inline notes in the latest commit: inlined the conversion, |
Prepare a host file with an extreme mtime and have the guest path_filestat_get and read it (p1 core module and p2 component runners). Also treat wall-clock conversions that fail for negative/out-of-range i64 timestamps as missing fields so the whole stat does not return OVERFLOW on platforms that clamp far- past times into i64. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Address review feedback: - Implement run() via run_with_workspace_setup() in p1, p2-sync, and p2-async so the runners are not duplicated. - Move host extreme-mtime workspace seeding into store::prepare_extreme_mtime_fixture for shared use. - Drop the unit test module in filesystem.rs now that integration coverage exists. cargo test -p wasmtime-wasi --features p1,p2 --test all p1_stat_extreme_host_mtime Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
alexcrichton
approved these changes
Jul 20, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Jul 20, 2026
MinGW merge-queue CI panicked at construct extreme SystemTime because FILETIME-based SystemTime cannot represent UNIX_EPOCH - (i64::MAX+1). Prefer that far-past value when available; otherwise fall back to the Windows epoch (~1601). Guest coverage still only requires that path_filestat_get does not panic the host. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Contributor
Author
|
Pushed a MinGW fix for the merge-queue failure on The extreme-mtime fixture used Happy to be re-queued when convenient. |
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
alexcrichton
enabled auto-merge
July 20, 2026 22:12
yagehu
pushed a commit
to yagehu/wasmtime-x
that referenced
this pull request
Jul 26, 2026
…codealliance#13894) * wasi: do not panic on extreme file timestamps in DescriptorStat Datetime::try_from can fail when SystemTime is outside the i64-second range. datetime_from used unwrap(), so a guest that set extreme timestamps on a preopened path could crash the host on the next stat. Map conversion failure to a missing timestamp (Option::None) instead. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> * wasi: rustfmt import order in filesystem.rs Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> * wasi: address review on DescriptorStat timestamp conversion Inline try_from mapping, drop narrative comments, and keep a small unit test under mod test for SystemTime values outside Datetime's range. Guest set_times cannot construct those values because they already use Datetime; host Metadata is the overflow path. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> * wasi: exercise extreme host mtime via guest filestat Prepare a host file with an extreme mtime and have the guest path_filestat_get and read it (p1 core module and p2 component runners). Also treat wall-clock conversions that fail for negative/out-of-range i64 timestamps as missing fields so the whole stat does not return OVERFLOW on platforms that clamp far- past times into i64. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> * wasi: share extreme-mtime fixture and dedupe test runners Address review feedback: - Implement run() via run_with_workspace_setup() in p1, p2-sync, and p2-async so the runners are not duplicated. - Move host extreme-mtime workspace seeding into store::prepare_extreme_mtime_fixture for shared use. - Drop the unit test module in filesystem.rs now that integration coverage exists. cargo test -p wasmtime-wasi --features p1,p2 --test all p1_stat_extreme_host_mtime Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> * wasi: make extreme-mtime fixture constructible on Windows MinGW merge-queue CI panicked at construct extreme SystemTime because FILETIME-based SystemTime cannot represent UNIX_EPOCH - (i64::MAX+1). Prefer that far-past value when available; otherwise fall back to the Windows epoch (~1601). Guest coverage still only requires that path_filestat_get does not panic the host. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> * wasi: rustfmt extreme_host_mtime fixture Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> --------- Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
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
2 participants
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
DescriptorStat::newconverted hostSystemTimevalues to WASIDatetimewithunwrap(). When conversion fails (time outside the representablei64second range), that panics the host while building file stats.Map conversion failure to
None(missing timestamp) on the existingOption<Datetime>fields.Failure scenario
Host
Metadatacan surfaceSystemTimevalues that do not fit WASIDatetime(for example extreme far-past times representable asSystemTimebut not asi64seconds). A subsequent guest or hoststatpath that buildsDescriptorStatwould panic instead of returning stats with missing timestamp fields.Guest
set_timesis not the reproducer for the overflow itself: those APIs already takeDatetimevalues within range. The panic is on host-side conversion ofSystemTimeintoDatetime.Origin
The previous description incorrectly attributed introduction to the cap-primitives migration (#13872). That PR refactored the conversion site; the unwrap-style failure mode is not claimed as newly introduced there. This change is a small hardening of the conversion.
Test
Unit test under
crates/wasi/src/filesystem.rs(mod test) asserts that extremeSystemTimevalues failDatetime::try_fromand map toNonewithout panicking.Integration coverage of the surrounding set_times/stat stack already exists as
p1_fd_filestat_setincrates/test-programs/crates/wasi/tests. A guest program cannot construct the overflowingSystemTimevia the public WASI timestamp APIs, so the edge case stays as a unit test on the conversion.