Petteri Aimonen

**Name of the Vulnerable Software and Affected Versions** Nanopb versions prior to 0.3.1 **Description** The issue allows size t overflows in `pb dec bytes` and `pb dec string`. **Recommendations** For versions prior to 0.3.1, update to version 0.3.1 or later to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Nanopb versions prior to 0.3.9.8 and 0.4.5 **Description** Decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. **Recommendations** For versions prior to 0.3.9.8, update to version 0.3.9.8. For versions prior to 0.4.5, update to version 0.4.5. As a temporary workaround, consider setting the option `no unions` for the oneof field to generate fields as separate instead of C union, which avoids triggering the problematic code. Alternatively, set the type of all fields inside the oneof to `FT POINTER` to ensure that the data contained inside the `union` is always a valid pointer. Heap implementations that guard against invalid `free()` provide a partial mitigation.

**Name of the Vulnerable Software and Affected Versions** Nanopb versions prior to 0.3.9.7 Nanopb versions prior to 0.4.4 **Description** Decoding specifically formed messages can leak memory if dynamic allocation is enabled and an oneof field contains a static submessage that contains a dynamic field, and the message being decoded contains the submessage multiple times. This is rare in normal messages, but it is a concern when untrusted data is parsed. **Recommendations** For versions prior to 0.3.9.7, update to version 0.3.9.7 to resolve the issue. For versions prior to 0.4.4, update to version 0.4.4 to resolve the issue. As a temporary workaround, consider setting the option `no unions` for the oneof field to generate fields as separate instead of C union. Alternatively, set the type of the submessage field inside oneof to `FT POINTER` to dynamically allocate the whole submessage. Using an arena allocator for nanopb can also ensure all memory can be released afterwards.