<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T21:48:46.371379+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2021-21401</id>
    <title>CVE-2021-21401 — Invalid free() call in Nanopb</title>
    <updated>2026-10-07T21:48:46.373301+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2021-21401"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-7mv5-5mxh-qg88</id>
    <title>GHSA-7mv5-5mxh-qg88 — nanopb vulnerable to invalid free() call with oneofs and PB_ENABLE_MALLOC</title>
    <updated>2026-10-07T21:48:46.373378+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-7mv5-5mxh-qg88"/>
  </entry>
</feed>
