Skip to content

winch: Don't treat memory_reservation as a bound when minimum exceeds it - #14619

Merged
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
saulecabrera:winch-issue-oob
Oct 11, 2026
Merged

alexcrichton merged 1 commit into
bytecodealliance:mainfrom
saulecabrera:winch-issue-oob

Conversation

@saulecabrera

@saulecabrera saulecabrera commented Oct 8, 2026 •

Copy link
Copy Markdown
Member

Closes: #14588

With memory_may_move disabled, Winch treated memory_reservation as an
upper bound on accessible memory and turned any access whose
offset + access size exceeded it into an unconditional trap. But when a
memory's minimum size is larger than the reservation, the runtime sizes
the allocation from the minimum instead, so in-bounds accesses past the
reservation trapped spuriously.

This removes the reservation clause, leaving maximum_byte_size as the
only compile-time out-of-bounds check, which matches Cranelift. Accesses
past the reservation now get the regular bounds check, which still traps
when the memory can't grow past the reservation.

@saulecabrera
saulecabrera requested review from a team as code owners October 8, 2026 23:49
@saulecabrera
saulecabrera requested review from alexcrichton and removed request for a team October 8, 2026 23:49
@saulecabrera saulecabrera changed the title winch: Don't treat memory_reservation as a bound when the minimum exc… winch: Don't treat memory_reservation as a bound minimum exceeds it Oct 8, 2026
@saulecabrera saulecabrera changed the title winch: Don't treat memory_reservation as a bound minimum exceeds it winch: Don't treat memory_reservation as a bound when minimum exceeds it Oct 9, 2026
@github-actions github-actions Bot added the winch Winch issues or pull requests label Oct 9, 2026
@github-actions

github-actions Bot commented Oct 9, 2026

Copy link
Copy Markdown

Subscribe to Label Action

cc @saulecabrera

Details This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

  • saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@alexcrichton alexcrichton left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Would it make sense to perhaps just remove this clause entirely? I'm having a tough time reasoning about the precise condition here and if it works just deleting the clause related to memory-reservation outright seems like a possibly simpler approach

…eeds it

With `memory_may_move` disabled, Winch treated `memory_reservation` as an
upper bound on accessible memory and turned any access whose
offset + access size exceeded it into an unconditional trap. But when a
memory's minimum size is larger than the reservation, the runtime sizes
the allocation from the minimum instead, so in-bounds accesses past the
reservation trapped spuriously.

This removes the reservation clause, leaving `maximum_byte_size` as the
only compile-time out-of-bounds check, which matches Cranelift. Accesses
past the reservation now get the regular bounds check, which still traps
when the memory can't grow past the reservation.
@saulecabrera

Copy link
Copy Markdown
Member Author

That makes sense to me @alexcrichton, I was not sure as well on the original motivation for this check (and admittedly took me a bit to wrap my head around it). I've removed it in 90d3cdd; decided to keep the run test since there was none covering this feature.

@alexcrichton
alexcrichton added this pull request to the merge queue Oct 10, 2026
Merged via the queue into bytecodealliance:main with commit 33c3c79 Oct 11, 2026
53 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

winch Winch issues or pull requests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Winch incorrectly reports an out-of-bound trap with some memory configuration

2 participants