CVE-2020-26243High· 7.5▾ TwilightMemory leak in Nanopb
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.5 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 8.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
2.6%
2.6% → 2.7%
Decoding specifically formed message 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.
Preliminary patch is available on git and problem will be patched in versions 0.3.9.7 and 0.4.4 once testing has been completed.
Following workarounds are available:
no_unions for the oneof field. This will generate fields as separate instead of C union, and avoids triggering the problematic code.FT_POINTER. This way the whole submessage will be dynamically allocated and the problematic code is not executed.Bug report: https://github.com/nanopb/nanopb/issues/615
If you have any questions or comments about this advisory, comment on the bug report linked above.
nanopb >= 0.3.2, < 0.3.9.7nanopb >= 0.4.0, < 0.4.4Upgrade to a patched release:
nanopb 0.3.9.7nanopb 0.4.4Connected by shared product, vendor, weakness, or advisory.