https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 19:45:05 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-22219 EUVD-2026-22219 https://cve.radiocsirt.org/vuln/euvd-2026-22219 https://cve.radiocsirt.org/vuln/fkie_cve-2021-21401 <p>Nanopb is a small code-size Protocol Buffers implementation in ansi C. In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. This has been fixed in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory for more information including workarounds.</p> <p>Nanopb is a small code-size Protocol Buffers implementation in ansi C. In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. This has been fixed in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory for more information including workarounds.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2021-21401 https://cve.radiocsirt.org/vuln/ghsa-7mv5-5mxh-qg88 <p><strong>Affected:</strong> PyPI: nanopb</p> <p>### Impact Decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed.</p> <p>### Patches Preliminary patch is available on git for [0.4.x](https://github.com/nanopb/nanopb/commit/e2f0ccf939d9f82931d085acb6df8e9a182a4261) and [0.3.x](https://github.com/nanopb/nanopb/commit/4a375a560651a86726e5283be85a9231fd0efe9c) branches. The fix will be released in versions 0.3.9.8 and 0.4.5 once testing has been completed.</p> <p>### Workarounds Following workarounds are available: * 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. * Set the type of all fields inside the oneof to `FT_POINTER`. This ensures that the data contained inside the `union` is always a valid pointer. * Heap implementations that guard against invalid `free()` provide a partial mitigation. Depending on the message type, the pointer value may be attacker controlled and can be used to bypass heap protections.</p> <p>### References Bug report: https://github.com/nanopb/nanopb/issues/647</p> <p>### For more information If…</p> <p><strong>Affected:</strong> PyPI: nanopb</p> <p>### Impact Decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed.</p> <p>### Patches Preliminary patch is available on git for [0.4.x](https://github.com/nanopb/nanopb/commit/e2f0ccf939d9f82931d085acb6df8e9a182a4261) and [0.3.x](https://github.com/nanopb/nanopb/commit/4a375a560651a86726e5283be85a9231fd0efe9c) branches. The fix will be released in versions 0.3.9.8 and 0.4.5 once testing has been completed.</p> <p>### Workarounds Following workarounds are available: * 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. * Set the type of all fields inside the oneof to `FT_POINTER`. This ensures that the data contained inside the `union` is always a valid pointer. * Heap implementations that guard against invalid `free()` provide a partial mitigation. Depending on the message type, the pointer value may be attacker controlled and can be used to bypass heap protections.</p> <p>### References Bug report: https://github.com/nanopb/nanopb/issues/647</p> <p>### For more information If…</p> https://cve.radiocsirt.org/vuln/ghsa-7mv5-5mxh-qg88 https://cve.radiocsirt.org/vuln/gsd-2021-21401 gsd-2021-21401 https://cve.radiocsirt.org/vuln/gsd-2021-21401 https://cve.radiocsirt.org/vuln/opensuse-su-2024:11074-1 <p>libprotobuf-nanopb0-0.4.5-1.3 on GA media</p> <p>libprotobuf-nanopb0-0.4.5-1.3 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:11074-1 https://cve.radiocsirt.org/vuln/pysec-2021-432 <p><strong>Affected:</strong> PyPI: nanopb</p> <p>Nanopb is a small code-size Protocol Buffers implementation in ansi C. In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. This has been fixed in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory for more information including workarounds.</p> <p><strong>Affected:</strong> PyPI: nanopb</p> <p>Nanopb is a small code-size Protocol Buffers implementation in ansi C. In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. This has been fixed in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory for more information including workarounds.</p> https://cve.radiocsirt.org/vuln/pysec-2021-432 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-21401 <p><strong>Affected:</strong> Ubuntu:Pro:20.04:LTS: nanopb</p> <p>Nanopb is a small code-size Protocol Buffers implementation in ansi C. In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. This has been fixed in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory for more information including workarounds.</p> <p><strong>Affected:</strong> Ubuntu:Pro:20.04:LTS: nanopb</p> <p>Nanopb is a small code-size Protocol Buffers implementation in ansi C. In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. This has been fixed in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory for more information including workarounds.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-21401