upb: reject non-delimited unknowns when promoting to message extensions

[baradika]

upb_MiniTable_ParseUnknownMessage consumed an unknown field as a length-delimited message without first verifying its wire type. upb_Message_FindUnknown2 matches unknowns by field number only and deliberately does not constrain the wire type, so an unknown of any other wire type could be returned for a message-typed extension's field number and then be misinterpreted as length-delimited.

In that case the field's own payload is read as the message length while the data pointer is already at the end of the unknown field, leaving the size passed to upb_Decode under attacker control and producing an out-of-bounds read.

Check the wire type immediately after reading the tag and return the existing parse error for non-delimited types. Only the delimited wire type carries a length prefix, so this rejects precisely the inputs that the length-prefix assumption does not hold for.

upb_Message_FindUnknown2 is intentionally left unchanged: its generic field-number semantics are required by its other callers.

Add regression tests for a zero-length varint payload (silently promoted to an empty message before this change) and for a 0xFFFFFFFF payload (out-of-bounds read caught by ASan), plus a control case confirming a well-formed length-delimited unknown still promotes.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.