admin/cvelist
1
0
Fork 0
mirror of https://github.com/CVEProject/cvelist.git synced 2025-08-04 08:44:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

"-Synchronized-Data."

Browse Source
This commit is contained in:
CVE Team 2020-11-25 17:01:45 +00:00
parent 57e07502f3
commit 0b11e649dc
No known key found for this signature in database
GPG Key ID: 5708902F06FEF743
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
2020/26xxx/CVE-2020-26243.json
View File

@ -38,7 +38,7 @@
"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.\n\nThis is fixed in versions 0.3.9.7 and 0.4.4.\n\nThe following workarounds are available: \n1) 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.\n2) 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.\n3) Use an arena allocator for nanopb, to make sure all memory can be released afterwards."
"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."
}
]
},