abi: bound-check QE AuthData ParsedDataSize before slicing

[evilgensec]

What

qeAuthDataToProto (abi/abi.go) reads a 16-bit ParsedDataSize from the QE AuthData of a TDX quote's certification data and uses it to slice the buffer:

authData.ParsedDataSize = uint32(binary.LittleEndian.Uint16(data[authDataParsedDataSizeStart:authDataParsedDataSizeEnd]))
authDataEnd := authDataParsedDataSizeEnd + authData.GetParsedDataSize()
authData.Data = data[authDataStart:authDataEnd]   // no bounds check

ParsedDataSize is fully attacker-controlled (it comes from the untrusted quote). If it is larger than the bytes actually present, data[authDataStart:authDataEnd] slices out of bounds and panics instead of returning an error. The validating length check in checkQeAuthData (which checks ParsedDataSize == len(Data)) runs on the next line — only after the slice — so it never executes in the out-of-bounds case.

Because the parse runs under the public verification entry points (abi.QuoteToProto → verify.RawTdxQuote) and there is no recover on that path, a malformed quote panics the verifier rather than being cleanly rejected.

A 2-byte input reproduces it directly:

qeAuthDataToProto([]byte{0xFF, 0xFF})
// panic: runtime error: slice bounds out of range [:65537] with capacity 2

Fix

Add the missing pre-slice bound check (mirroring the existing pre-slice length checks in certificationDataToProto and signedDataToProto), plus a short-buffer guard for the ParsedDataSize read itself, so malformed QE AuthData is rejected with an error instead of panicking.

Testing

go test ./abi/... passes, including two new regression tests: an out-of-bounds ParsedDataSize and a too-short buffer now both return an error rather than panicking.