{"containers": {"cna": {"affected": [{"product": "nanopb", "vendor": "nanopb", "versions": [{"status": "affected", "version": "< 0.3.9.7"}, {"status": "affected", "version": ">= 0.4.0, < 0.4.4"}]}], "descriptions": [{"lang": "en", "value": "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."}], "metrics": [{"cvssV3_1": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 7.5, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}}], "problemTypes": [{"descriptions": [{"cweId": "CWE-20", "description": "CWE-20: Improper Input Validation", "lang": "en", "type": "CWE"}]}, {"descriptions": [{"cweId": "CWE-119", "description": "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer", "lang": "en", "type": "CWE"}]}], "providerMetadata": {"dateUpdated": "2020-11-25T16:50:15", "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M"}, "references": [{"tags": ["x_refsource_CONFIRM"], "url": "https://github.com/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh"}, {"tags": ["x_refsource_MISC"], "url": "https://github.com/nanopb/nanopb/issues/615"}, {"tags": ["x_refsource_MISC"], "url": "https://github.com/nanopb/nanopb/commit/4fe23595732b6f1254cfc11a9b8d6da900b55b0c"}, {"tags": ["x_refsource_MISC"], "url": "https://github.com/nanopb/nanopb/blob/2b48a361786dfb1f63d229840217a93aae064667/CHANGELOG.txt"}], "source": {"advisory": "GHSA-85rr-4rh9-hhwh", "discovery": "UNKNOWN"}, "title": "Memory leak in nanopb", "x_legacyV4Record": {"CVE_data_meta": {"ASSIGNER": "[email protected]", "ID": "CVE-2020-26243", "STATE": "PUBLIC", "TITLE": "Memory leak in nanopb"}, "affects": {"vendor": {"vendor_data": [{"product": {"product_data": [{"product_name": "nanopb", "version": {"version_data": [{"version_value": "< 0.3.9.7"}, {"version_value": ">= 0.4.0, < 0.4.4"}]}}]}, "vendor_name": "nanopb"}]}}, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": {"description_data": [{"lang": "eng", "value": "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."}]}, "impact": {"cvss": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 7.5, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}}, "problemtype": {"problemtype_data": [{"description": [{"lang": "eng", "value": "CWE-20: Improper Input Validation"}]}, {"description": [{"lang": "eng", "value": "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer"}]}]}, "references": {"reference_data": [{"name": "https://github.com/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh", "refsource": "CONFIRM", "url": "https://github.com/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh"}, {"name": "https://github.com/nanopb/nanopb/issues/615", "refsource": "MISC", "url": "https://github.com/nanopb/nanopb/issues/615"}, {"name": "https://github.com/nanopb/nanopb/commit/4fe23595732b6f1254cfc11a9b8d6da900b55b0c", "refsource": "MISC", "url": "https://github.com/nanopb/nanopb/commit/4fe23595732b6f1254cfc11a9b8d6da900b55b0c"}, {"name": "https://github.com/nanopb/nanopb/blob/2b48a361786dfb1f63d229840217a93aae064667/CHANGELOG.txt", "refsource": "MISC", "url": "https://github.com/nanopb/nanopb/blob/2b48a361786dfb1f63d229840217a93aae064667/CHANGELOG.txt"}]}, "source": {"advisory": "GHSA-85rr-4rh9-hhwh", "discovery": "UNKNOWN"}}}, "adp": [{"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-04T15:56:04.801Z"}, "title": "CVE Program Container", "references": [{"tags": ["x_refsource_CONFIRM", "x_transferred"], "url": "https://github.com/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh"}, {"tags": ["x_refsource_MISC", "x_transferred"], "url": "https://github.com/nanopb/nanopb/issues/615"}, {"tags": ["x_refsource_MISC", "x_transferred"], "url": "https://github.com/nanopb/nanopb/commit/4fe23595732b6f1254cfc11a9b8d6da900b55b0c"}, {"tags": ["x_refsource_MISC", "x_transferred"], "url": "https://github.com/nanopb/nanopb/blob/2b48a361786dfb1f63d229840217a93aae064667/CHANGELOG.txt"}]}]}, "cveMetadata": {"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "assignerShortName": "GitHub_M", "cveId": "CVE-2020-26243", "datePublished": "2020-11-25T16:50:15", "dateReserved": "2020-10-01T00:00:00", "dateUpdated": "2024-08-04T15:56:04.801Z", "state": "PUBLISHED"}, "dataType": "CVE_RECORD", "dataVersion": "5.1"}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:nanopb_project:nanopb:*:*:*:*:*:*:*:*", "matchCriteriaId": "E2479C6C-033B-4F28-895E-9ACDEB6956F2", "versionEndExcluding": "0.3.9.7", "vulnerable": true}, {"criteria": "cpe:2.3:a:nanopb_project:nanopb:*:*:*:*:*:*:*:*", "matchCriteriaId": "42DF75C8-803B-4F1A-AF78-929126981CBB", "versionEndExcluding": "0.4.4", "versionStartIncluding": "0.4.0", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "descriptions": [{"lang": "en", "value": "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."}, {"lang": "es", "value": "Nanopb es una implementaci\u00f3n de B\u00faferes de Protocolo de c\u00f3digo de tama\u00f1o peque\u00f1o. En Nanopb versiones anteriores a 0.4.4 y 0.3.9.7, la decodificaci\u00f3n de un mensaje formado espec\u00edficamente puede filtrar la memoria si es habilitada la asignaci\u00f3n din\u00e1mica y un campo contiene un submensaje est\u00e1tico que contiene un campo din\u00e1mico, y el mensaje que est\u00e1 siendo decodificado contiene el submensaje varias veces. Esto es raro en los mensajes normales, pero es preocupante cuando son analizados datos no fiables. Esto est\u00e1 corregido en las versiones 0.3.9.7 y 0.4.4. Est\u00e1n disponibles las siguientes soluciones provisionales: 1) Poner la opci\u00f3n \"no_unions\" para el campo uno. Esto generar\u00e1 campos como separados en lugar de la uni\u00f3n C, y evita desencadenar el c\u00f3digo problem\u00e1tico. 2) Ajustar el tipo de campo de submensaje dentro de uno de ellos a \"TP_POINTER\". De esta manera todo el submensaje ser\u00e1 asignado din\u00e1micamente y el c\u00f3digo problem\u00e1tico no ser\u00e1 ejecutado. 3) Usar un asignador de campos para el nanopb, para asegurarse de que toda la memoria pueda ser liberada despu\u00e9s"}], "id": "CVE-2020-26243", "lastModified": "2024-11-21T05:19:38.063", "metrics": {"cvssMetricV2": [{"acInsufInfo": false, "baseSeverity": "MEDIUM", "cvssData": {"accessComplexity": "MEDIUM", "accessVector": "NETWORK", "authentication": "NONE", "availabilityImpact": "PARTIAL", "baseScore": 4.3, "confidentialityImpact": "NONE", "integrityImpact": "NONE", "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "version": "2.0"}, "exploitabilityScore": 8.6, "impactScore": 2.9, "obtainAllPrivilege": false, "obtainOtherPrivilege": false, "obtainUserPrivilege": false, "source": "[email protected]", "type": "Primary", "userInteractionRequired": false}], "cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 7.5, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 3.6, "source": "[email protected]", "type": "Secondary"}, {"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 7.5, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 3.6, "source": "[email protected]", "type": "Primary"}]}, "published": "2020-11-25T17:15:12.200", "references": [{"source": "[email protected]", "tags": ["Release Notes", "Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/blob/2b48a361786dfb1f63d229840217a93aae064667/CHANGELOG.txt"}, {"source": "[email protected]", "tags": ["Patch", "Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/commit/4fe23595732b6f1254cfc11a9b8d6da900b55b0c"}, {"source": "[email protected]", "tags": ["Exploit", "Patch", "Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/issues/615"}, {"source": "[email protected]", "tags": ["Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Release Notes", "Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/blob/2b48a361786dfb1f63d229840217a93aae064667/CHANGELOG.txt"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Patch", "Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/commit/4fe23595732b6f1254cfc11a9b8d6da900b55b0c"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Exploit", "Patch", "Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/issues/615"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Third Party Advisory"], "url": "https://github.com/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh"}], "sourceIdentifier": "[email protected]", "vulnStatus": "Modified", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-20"}, {"lang": "en", "value": "CWE-119"}], "source": "[email protected]", "type": "Secondary"}]}

{"bugzilla": {"description": "nanopb: oneof fields with PB_ENABLE_MALLOC can leak memory", "id": "1902065", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1902065"}, "csaw": false, "cvss3": {"cvss3_base_score": "7.5", "cvss3_scoring_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-20->CWE-119", "details": ["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.", "A flaw was found nanopd. If dynamic allocation is enabled and the oneof field contains a static sub-message, an attacker can use this flaw to leak memory potentially resulting in a denial of service. The highest threat from this vulnerability is to system availability."], "name": "CVE-2020-26243", "package_state": [{"cpe": "cpe:/a:redhat:service_mesh:1", "fix_state": "Will not fix", "impact": "moderate", "package_name": "servicemesh-proxy", "product_name": "OpenShift Service Mesh 1"}], "public_date": "2020-11-25T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2020-26243\nhttps://nvd.nist.gov/vuln/detail/CVE-2020-26243\nhttps://github.com/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh"], "statement": "OpenShift ServiceMesh (OSSM) packages a vulnerable version of nanopb in the RPM servicemesh-proxy, however it does not define PB_ENABLE_MALLOC and hence the code in pb_release_union_field is never reached. As such, OSSM is deemed to be of Moderate impact and marked wontfix at this time although it may be fixed in a future update.", "threat_severity": "Important", "upstream_fix": "nanopb 0.3.9.7, nanopb 0.4.4"}