Crash seems to be related to endianness, it is crashing when executing this snippet:
https://github.com/maistra/header-append-filter/blob/maistra-2.1/src/lib.rs#L12

Here is a trace of wasm functions as well as memory load/stores at runtime on s390, being executed by V8:
```
   3:   *wasm-function[112] "_ZN97_$LT$header_append_filter..HeaderAppendRootContext$u20$as$u20$proxy_wasm..traits..RootContext$GT$12on_configure17hb096d7d7897669caE" {
   4:    *wasm-function[155] "_ZN10proxy_wasm9hostcalls17get_configuration17h9a61b6e0a4b4b5c2E" {
turbofan    func:   155+0x18     store to 0000000001048288 val: i32:0 / 00000000
turbofan    func:   155+0x1f     store to 0000000001048292 val: i32:0 / 00000000
   5:     *wasm-function[461] "malloc" {
   6:      *wasm-function[125] "__rust_alloc" {
   7:       *wasm-function[326] "__rdl_alloc" {
   8:        *wasm-function[307] "_ZN8dlmalloc17Dlmalloc$LT$A$GT$6malloc17h25d3e8a45fd7c029E" {
   9:         *wasm-function[308] "_ZN8dlmalloc8dlmalloc17Dlmalloc$LT$A$GT$6malloc17h817d0bdbe748994dE" {
  10:          *wasm-function[341] "_ZN8dlmalloc8dlmalloc8align_up17h1071ebba4314c5a2E" {
  10:          } -> 16
  10:          *wasm-function[341] "_ZN8dlmalloc8dlmalloc8align_up17h1071ebba4314c5a2E" {
  10:          } -> 80
turbofan    func:   308+0x345   load from 0000000001064048 val: i32:0 / 00000000
turbofan    func:   308+0x366   load from 0000000001064448 val: i32:0 / 00000000
turbofan    func:   308+0x376   load from 0000000001064052 val: i32:0 / 00000000
turbofan    func:   308+0x6b4   load from 0000000001064448 val: i32:0 / 00000000
turbofan    func:   308+0x6c4   load from 0000000001064452 val: i32:65392 / 0000ff70
turbofan    func:   308+0x11f6   store to 0000000001064452 val: i32:65312 / 0000ff20
turbofan    func:   308+0x1201  load from 0000000001064460 val: i32:1114216 / 00110068
  10:          *wasm-function[357] "_ZN8dlmalloc8dlmalloc5Chunk11plus_offset17h7aa5253a4344ed9aE" {
  10:          } -> 1114296
turbofan    func:   308+0x1214   store to 0000000001064460 val: i32:1114296 / 001100b8
turbofan    func:   308+0x1222   store to 0000000001114300 val: i32:65313 / 0000ff21
  10:          *wasm-function[354] "_ZN8dlmalloc8dlmalloc5Chunk34set_size_and_pinuse_of_inuse_chunk17hf4d697bb61df28bcE" {
turbofan    func:   354+0x8      store to 0000000001114220 val: i32:83 / 00000053
  10:          }
  10:          *wasm-function[359] "_ZN8dlmalloc8dlmalloc5Chunk6to_mem17he3242996ca597cecE" {
  10:          } -> 1114224
   9:         } -> 1114224
   8:        } -> 1114224
   7:       } -> 1114224
   6:      } -> 1114224
   5:     } -> 1114224
turbofan    func:   155+0x3b    load from 0000000001048288 val: i32:1879052544 / 70001100
```

Wasm is LE enforced. V8 is hardcoded to reverse the bytes with every Wasm load/store operation done on BE machines.
Note the last line above is loading the value `1114224` in reverse which becomes `70001100` in hexadecimal.

Same line on x64 looks like this which loads the value correctly (`00110070` in hexadecimal)
```
turbofan    func:   155+0x3b    load from 0000000001048288 val: i32:1114224 / 00110070
```
This shows the original value being loaded by s390 was not stored in LE enforced order and probably was stored in machine BE order.

I disassembled the generated wasm binary file created by https://github.com/maistra/header-append-filter.
I noticed the hostcall function being executed under `...wasm9hostcalls17get_configuration...` is `proxy_get_configuration`:
```
00d158: 10 83 80 80 80 00          |   call 3 <proxy_get_configuration>
```

This function isn't defined in this wasm module, a quick googling shows it's implemented by Rust SDK ?
https://github.com/proxy-wasm/proxy-wasm-rust-sdk/issues/104

If so then the value might be being written to memory in native machine order and being reversed at runtime by V8 which will corrupt it.