Avoid string_view underflow in ParseCodeMetadataAnnotation

[aizu-m]

ASAN, wat2wasm --enable-annotations on a (@custom ...) sat inside a function body:

ERROR: AddressSanitizer: heap-buffer-overflow READ of size 8
  #5 std::__string_view_hash::operator()(std::string_view)
  #9 wabt::BinaryWriter::WriteExpr() binary-writer.cc:1189
  #11 wabt::BinaryWriter::WriteFunc() binary-writer.cc:1229

ParseCodeMetadataAnnotation strips the metadata.code. prefix with remove_prefix(14) and assumes it is always there. ParseInstrList hands it every (@...) annotation in an instruction list, and Peek admits the bare (@custom ...) token because that spelling is meaningful at module scope. On the 6-byte custom text remove_prefix(14) underflows the view length to ~2^64 and walks the data pointer past the token. The CodeMetadataExpr then keeps a name whose pointer and size are both rubbish. Nothing trips until the binary writer hashes that name as a map key, which is where ASAN fires.

The binary reader already guards the matching strip with find("metadata.code.") == 0 in binary-reader.cc; the parser never got it. Reject annotations without the prefix.

Repro:

(module
  (func
    (@custom "x")))

Turned up fuzzing wat2wasm with annotations enabled.

[sbc100]

Should this be an error, or something we just skip over in ParseCodeMetadataAnnotation?

[aizu-m]

Switched it to skip. Peek already discards every annotation it does not recognise; the only reason a non-metadata.code one lands here is the cur.text() == "custom" branch admitting custom for module-scope custom sections. So erroring would single out custom while (@foo ...) and the rest get dropped silently, and the binary reader already skips unknown custom sections too. Skipping keeps it consistent. It now eats the annotation’s balanced parens and carries on, and a real metadata.code annotation in the same body is still emitted. Reworked the test into a dump that shows both.

[sbc100]

(Nit: Please start the PR titles with a capital letter).

[aizu-m]

Title capitalised, thanks. Also flipped the handling from a parse error to skipping the annotation per the inline note.

[sbc100]

Do we not require C++20 so don't have str.starts_with

[aizu-m]

Right, we're on C++17 here (CMAKE_CXX_STANDARD 17 in CMakeLists), so no starts_with. Went with find(...) != 0 to match the existing prefix check in Peek at wast-parser.cc:598, which tests the same string the same way.