CVE-2020-26243: 
Python vulnerability analysis and mitigation

Nanopb, a small code-size Protocol Buffers implementation, disclosed a vulnerability (CVE-2020-26243) affecting versions before 0.4.4 and 0.3.9.7. The vulnerability was discovered and reported on November 24, 2020, and fixed in versions 0.3.9.7 and 0.4.4 released on November 25, 2020. The issue affects systems where dynamic allocation is enabled and specific message structures containing oneof fields are used (GitHub Advisory).

The vulnerability occurs when decoding specifically formed messages with PB_ENABLE_MALLOC enabled. The issue manifests when an oneof field contains a static submessage that contains a dynamic field, and the message being decoded contains the submessage multiple times. The bug was caused by pb_release_union_field detecting duplicate submessages but not properly handling memory management, leading to a memory leak. The issue received a CVSS v3.1 score of 7.5 HIGH (NVD).

When exploited, the vulnerability results in memory leaks when parsing maliciously crafted messages. The impact increases with the number of duplicate fields in the message, with each duplicate potentially causing additional memory leaks. For example, certain test cases showed that specific message patterns could leak 4 bytes, and larger patterns could leak 8 bytes or more (GitHub Issue).

The vulnerability can be triggered when processing untrusted input data that contains specifically crafted messages with duplicate fields. While this condition is rare in normal messages, it becomes a significant concern when parsing untrusted data. A proof-of-concept exploit was documented in the issue report demonstrating how to trigger the memory leak (GitHub Issue).

Three workarounds were provided: 1) Set the option 'no_unions' for the oneof field to generate fields as separate instead of C union, 2) Set the type of the submessage field inside oneof to 'FT_POINTER' to ensure dynamic allocation of the whole submessage, 3) Use an arena allocator for nanopb to ensure all memory can be released afterwards. The permanent fix was implemented in versions 0.3.9.7 and 0.4.4 (GitHub Advisory).