| 39e910be | 09-Apr-2026 |
Alex Crichton <[email protected]> |
[44.0.0] Merged backports for security advisories (#13007)
* fix(environ): repair unsound StringPool::try_clone()
The 43.0 release introduced a soundness bug in StringPool::try_clone(): the
cloned
[44.0.0] Merged backports for security advisories (#13007)
* fix(environ): repair unsound StringPool::try_clone()
The 43.0 release introduced a soundness bug in StringPool::try_clone(): the
cloned map retains &'static str keys pointing into the original pool's
strings storage. Once the original Linker is dropped those keys dangle.
Cloning a Linker, then dropping the original one, leaves a linker whose
registered imports could no longer be found, causing instantiation to
fail with "unknown import".
Signed-off-by: Flavio Castelli <[email protected]>
* Fix pooling allocator predicate to reset VM permissions
This commit fixes a mistake that was introduced in #9583 where the logic
to reset a linear memory slot in the pooling allocator used the wrong
predicate. Specifically VM permissions must be reset if virtual memory
can be relied on at all, and the preexisting predicate of
`can_elide_bounds_check` was an inaccurate representation of this. The
correct predicate to check is `can_use_virtual_memory`.
* winch: Fix the type of the `table.size` output register
This commit corrects the tagged size of the output of the `table.size`
instruction. Previously this was hardcoded as a 32-bit integer instead
of consulting the table's index type to use the
index-type-sized-register instead.
* winch: Fix a host panic when executing `table.fill`
This commit fixes a possible panic when a Winch-compiled module executes
the `table.fill` instruction. Refactoring in #11254 updated Cranelift
but forgot to update Winch meaning that Winch's indices were still using
the module-level indices instead of the `DefinedTableIndex` space. This
adds some tests and updates Winch's translation to use preexisting
helpers.
* x64: Fix `f64x2.splat` without SSE3
Don't sink a load into `pshufd` which loads 16 bytes, instead force
`put_in_xmm` to ensure only 8 bytes are loaded.
* Properly verify alignment in string transcoding
This commit updates string transcoding between guest modules to properly
verify alignment. Previously alignment was only verified on the first
allocation, not reallocations, which is not spec-compliant. This
additionally fixes a possible host panic when dealing with unaligned
pointers.
* Fix type confusion in AArch64 amode RegScaled folding
* winch: Add add_uextend to perform explicit extension when needed.
This commit fixes an out-of-bounds access caused by the lack zero
extension in the code responsible for calculating the heap address for
loads/stores.
This issue manifests in aarch64 (unlike x64) given that no automatic
extension is performed, resulting in an out-of-bounds access.
An alternative approach is to emit an extend for the index, however
this approach is preferred given that it gives the MacroAssembler
layer better control of how to lower addition, e.g., in aarch64 we can
inline the desired extension in a single instruction.
* winch: Correctly type the result of table.grow
This commit fixes an out-of-bounds access caused by the lack of type
narrowing from the `table.grow` builtin. Without explicit narrowing,
the type is treated as 64-bit value, which could cause issues when
paired with loads/stores.
* Review comments
* Properly handle table index types
Only narrow when dealing with the 64-bit pointer/32-bit tables
* Fix panic with out-of-bounds flags in `Value`
This commit fixes a panic when a component model `Value` is lifted from
a flags value which specifies out-of-bounds bits as 1. This is specified
in the component model to ignore the out-of-bounds bits, which `flags!`
correctly did (and thus `bindgen!`), but `Value` treated out-of-bounds
bits as a panic due to indexing an array.
* Fix bounds checks in FACT's `string_to_compact` method
We need to bounds check the source byte length, not the number of code units.
* Add missing realloc validation in string transcoding
This commit adds a missing validation that a return value of `realloc`
is inbounds during string transcoding. This was accidentally missing on
the transcoding path from `utf8` to `latin1+utf16` which meant that a
nearly-raw pointer could get passed to the host to perform the
transcode.
* winch: Refine zero extension heuristic
This commit refines the zero extension heuristic such that it
unconditionally emits a zero extension when dealing with 32-bit
heaps. This eliminates any ambiguity related to the value of the
memory indices across ISAs.
* Fix failure on 32-bit
* Fix miri test
---------
Signed-off-by: Flavio Castelli <[email protected]>
Co-authored-by: Flavio Castelli <[email protected]>
Co-authored-by: Shun Kashiwa <[email protected]>
Co-authored-by: Saúl Cabrera <[email protected]>
Co-authored-by: Nick Fitzgerald <[email protected]>
show more ...
|
| 7e432118 | 03-Apr-2026 |
Alex Crichton <[email protected]> |
riscv64: Fix `uadd_overflow` for 32-bit integers (#12951)
This commit fixes a mistake from #11583 where the implementation of
`uadd_overflow` on riscv64 was not correct for some inputs. This fix
gen
riscv64: Fix `uadd_overflow` for 32-bit integers (#12951)
This commit fixes a mistake from #11583 where the implementation of
`uadd_overflow` on riscv64 was not correct for some inputs. This fix
generates the same codegen as `uadd_overflow_trap` which is to
zero-extend both inputs, perform a 64-bit add, and use the 33rd bit as
the overflow flag.
This sequence does notably differ from what LLVM generates. For example
this input function
#[unsafe(no_mangle)]
pub fn uadd_overflow(a: u64, b: u64) -> (u32, bool) {
(a as u32).overflowing_add(b as u32)
}
generates:
uadd_overflow:
addw a0, a0, a1
sext.w a1, a1
sltu a1, a0, a1
ret
While this is probably correct I find it tough to reason about how
`addw` produces a sign-extended result, `sext.w` sign-extends one of the
operands, and then an unsigned comparison is used to generate the
overflow flag for an unsigned addition. Overall I felt it was easier to
just match the `uadd_overflow_trap` codegen.
show more ...
|
| 2a50190f | 03-Apr-2026 |
Alex Crichton <[email protected]> |
x64: Fix possible overflow in `Amode::offset` (#12949)
* x64: Fix possible overflow in `Amode::offset`
This commit fixes an issue in the x64 backend of Cranelift where the
`Amode::offset` method co
x64: Fix possible overflow in `Amode::offset` (#12949)
* x64: Fix possible overflow in `Amode::offset`
This commit fixes an issue in the x64 backend of Cranelift where the
`Amode::offset` method contained unchecked arithmetic meaning that it
could possibly overflow. This in turn could lead to a miscompile of
loading/storing 128-bit integers where this method is used to generate
an `Amode` that is 8 bytes beyond the based address to load the upper
bits. This miscompile isn't reachable from WebAssembly but is
nonetheless still a good bugfix to have for Cranelift.
The fix here is to switch the `Amode::offset` method to being fallible,
returning `None` on overflow. This then propagates up into ISLE where
the `amode_offset` helper now has a separate case for when the addition
fails, using `lea` to generate a register with an address in it. This
then subsequently also needed fixing for various `Atomic128*` operations
where instead of storing just a single `SyntheticAmode` they now store
two, one for the address of the low bits and one for the address of the
high bits.
* Fix tests
Notably package up all the arguments into a boxed structure for the
atomic128 ops to avoid making `Inst` too large.
* Fix clippy
show more ...
|
| baa6b27b | 26-Mar-2026 |
Chris Fallin <[email protected]> |
Cranelift: rework MachBuffer to handle very short-deadline jumps. (#12842)
* Cranelift: rework MachBuffer to handle very short-deadline jumps.
In #12811 it was reported that riscv64 compressed jump
Cranelift: rework MachBuffer to handle very short-deadline jumps. (#12842)
* Cranelift: rework MachBuffer to handle very short-deadline jumps.
In #12811 it was reported that riscv64 compressed jumps (`c.j`
instructions), with a +/- 2048-byte range, could cause panics when
combined with queued-up/deferred constants in a constant pool during
binary emission.
Our `MachBuffer` handles single-pass machine code emission, resolution
of labels, and upgrading of label ranges via "veneers" (jumps that a
shorter jump can reach that themselves have a longer range). We track a
pending "deadline" of all unresolved branches, and when the deadline is
too close (including the max size of all veneers yet to be emitted), we
emit an "island" of all veneers to resolve the deadline.
After its initial design, we added support for deferred traps and
constants to the `MachBuffer`. These worked by emitting their contents
*before* the "island" of veneers, which turns out to be slightly nicer
for code layout in some cases.
Unfortunately the full implications of those additions weren't realized
against the invariants of the deadline-resolution algorithm. In
particular, when a new branch is added with a very short range (e.g.,
`c.j`), it is possible that there are *already* too many queued-up
traps/constants for the range of that just-emitted branch to reach even
the first possible veneer site if we start an island right away.
Thus it is strictly necessary to emit the veneers before
constants/traps. Unfortunately this requires some alterations to other
aspects of label resolution as well: in particular, we can't resolve
fixups for label references to constants before we emit those constants,
and likewise for traps. Note that we do a fixpoint loop over emitting
island(s) at the end of emission, so all constants/traps *will* be
emitted and label references to them *will* be resolved eventually; just
in the opposite order, now.
No compile test because the particular reduced testcase in #12811 only
worked in the `release-36.0.0` branch, and not on `main`, and it was too
hard to tweak the test to hit the right case on `main` as well. In lieu
of that, I've added a unit test directly to the `MachBuffer`
implementation to exercise this case.
Fixes #12811.
* fix filetest with errant comments confusing precise-output check
show more ...
|
| 4c4ef395 | 18-Mar-2026 |
Alex Crichton <[email protected]> |
aarch64: Make `csdb` in `JTSequence` conditional (#12798)
Make this instruction's emission conditional based on
`enable_table_access_spectre_mitigation` which is a rough equivalent
in terms of preex
aarch64: Make `csdb` in `JTSequence` conditional (#12798)
Make this instruction's emission conditional based on
`enable_table_access_spectre_mitigation` which is a rough equivalent
in terms of preexisting Cranelift settings. In #12789 it's shown that
this instruction has a very large performance impact on macOS aarch64 at
least, and currently there's no way to turn this off even for testing.
The goal of this commit is to at least not tamper with defaults while
providing an escape hatch. This notably doesn't fix #12789 because this
is such an obscure option I'd personally say the true thing to resolve
is the default behavior, not knobs.
show more ...
|