Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

AlignmentLowering: an out-of-bounds unaligned store becomes a partial write

Ouverte
  • Quelque chose ne va pas ?
#9,186 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
52/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
wasm
Domaine
compilers

Piste de recherche

Start by locating the AlignmentLowering and i64-to-i32-lowering implementations, then run the provided wasm-opt reproducer with --alignment-lowering and --fuzz-exec. Check both affected passes for multi-byte stores near the memory boundary. Done means an out-of-bounds store traps without modifying memory in both passes, while valid stores retain their behavior.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

An unaligned i32.store align=1 is split into four i32.store8s. If the address is out of bounds, the first bytes are written and the later ones trap, so memory differs after the trap. In the spec, a store whose bytes do not all fit in the memory reduces to trap without changing the store (Step/store-num-oob), so a trapping store never writes anything.

Root cause

The byte stores are emitted in increasing address order. The last byte is the one that traps, and the earlier stores have already happened.

Affected passes

--alignment-lowering and --i64-to-i32-lowering. The latter writes the low word of an i64.store before the high word traps.

Reproducer
(module
 (memory 1 1)
 (func (export "store")
  (i32.store align=1 (i32.const 65534) (i32.const 0x01020304)))
 (func (export "peek") (result i32)
  (i32.load (i32.const 65532))))

$ wasm-opt in.wat --alignment-lowering --print
 (func $0
  (local $0 i32)
  (local $1 i32)
  (local.set $0 (i32.const 65534))
  (local.set $1 (i32.const 16909060))
  (i32.store8 (local.get $0) (local.get $1))
  (i32.store8 offset=1 (local.get $0) (i32.shr_u (local.get $1) (i32.const 8)))
  (i32.store8 offset=2 (local.get $0) (i32.shr_u (local.get $1) (i32.const 16)))
  (i32.store8 offset=3 (local.get $0) (i32.shr_u (local.get $1) (i32.const 24)))
 )

The 4-byte store at 65534 in a 1-page memory is out of bounds, so it must trap without writing. peek reads the last word afterwards:

$ wasm-opt in.wat --alignment-lowering --fuzz-exec -o /dev/null
[fuzz-exec] export store
[trap highest > memory: 65534 > 65532]
[fuzz-exec] export peek
[fuzz-exec] note result: peek => 0
[fuzz-exec] export store
[trap highest > memory: 65536 > 65535]
[fuzz-exec] export peek
[fuzz-exec] note result: peek => 50593792
[fuzz-exec] comparing peek
values not identical! 50593792 != 0
[fuzz-exec] optimization passes changed results
Expected vs actual

The original traps with memory unchanged. After --alignment-lowering the first two byte stores succeed and the third traps; the last word becomes 50593792 (0x03040000).

Version

Reproduced on upstream main at 4d8ac549e2ab9b283246ea95e79ebe139ca579ac (wasm-opt version 133).

AI was used as part of the process of finding this issue. I have manually checked and reproduced it.

Langage dominant
WebAssembly
Étoiles
8.7k
Forks
893
Merge moyen
1 j 15 h
PR mergées (30 j)
79

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de WebAssembly/binaryen

Toutes les issues de WebAssembly/binaryen

Issues similaires

Plus d'issues Compilers

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.