vulgraph opened issue #13222:
On
release-29.0.0, CVE-2026-24116 /728fa071hasn't been picked up. The vulnerability is the x64fcopysignlowering allowing anf64.loadto sink in and widen to a 128-bit read, which can segfault when Wasmtime runs without signals-based traps.
cranelift/codegen/src/isa/x64/lower.isle(shaab44d23a) still has the originalfcopysignrules with noXmm-coercion ofa/band noforce into reg so we don't sink a 128-bit load.comment. The regression teststests/disas/f64-copysign.watandtests/misc_testsuite/f64-copysign.wastintroduced upstream are also absent.If
release-29.0.0is in scope for security backports, the cherry-pick is small (4 lines plus tests) — I can put up the PR.Thanks,
vulgraph
alexcrichton closed issue #13222:
On
release-29.0.0, CVE-2026-24116 /728fa071hasn't been picked up. The vulnerability is the x64fcopysignlowering allowing anf64.loadto sink in and widen to a 128-bit read, which can segfault when Wasmtime runs without signals-based traps.
cranelift/codegen/src/isa/x64/lower.isle(shaab44d23a) still has the originalfcopysignrules with noXmm-coercion ofa/band noforce into reg so we don't sink a 128-bit load.comment. The regression teststests/disas/f64-copysign.watandtests/misc_testsuite/f64-copysign.wastintroduced upstream are also absent.If
release-29.0.0is in scope for security backports, the cherry-pick is small (4 lines plus tests) — I can put up the PR.Thanks,
vulgraph
alexcrichton commented on issue #13222:
See https://github.com/bytecodealliance/wasmtime/issues/13220 and https://github.com/bytecodealliance/wasmtime/issues/13221. You can read more about our release process here: https://docs.wasmtime.dev/stability-release.html
vulgraph commented on issue #13222:
Thanks for the cross-link to the policy explanation in the sister thread — got it, no further action needed here. Closing.
Last updated: May 03 2026 at 22:13 UTC