Lucene search

K
cvelistGitHub_MCVELIST:CVE-2020-26243
HistoryNov 25, 2020 - 4:50 p.m.

CVE-2020-26243 Memory leak in nanopb

2020-11-2516:50:15
CWE-20
CWE-119
GitHub_M
www.cve.org

7.5 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

0.003 Low

EPSS

Percentile

71.6%

Nanopb is a small code-size Protocol Buffers implementation. In Nanopb before versions 0.4.4 and 0.3.9.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. This is fixed in versions 0.3.9.7 and 0.4.4. The following workarounds are available: 1) Set the option no_unions for the oneof field. This will generate fields as separate instead of C union, and avoids triggering the problematic code. 2) Set the type of the submessage field inside oneof to FT_POINTER. This way the whole submessage will be dynamically allocated and the problematic code is not executed. 3) Use an arena allocator for nanopb, to make sure all memory can be released afterwards.

CNA Affected

[
  {
    "product": "nanopb",
    "vendor": "nanopb",
    "versions": [
      {
        "status": "affected",
        "version": "< 0.3.9.7"
      },
      {
        "status": "affected",
        "version": ">= 0.4.0, < 0.4.4"
      }
    ]
  }
]

7.5 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

0.003 Low

EPSS

Percentile

71.6%