<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 22:58:23 +0000</lastBuildDate>
    <item>
      <title>CVE-2023-45666 — Possible double-free or memory leak in stbi__load_gif_main in stb_image</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2023-45666</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; nothings stb, nothings stb_image&lt;/p&gt;
&lt;p&gt;stb_image is a single file MIT licensed library for processing images.  It may look like `stbi__load_gif_main` doesn’t give guarantees about the content of output value `*delays` upon failure. Although it sets `*delays` to zero at the beginning, it doesn’t do it in case the image is not recognized as GIF and a call to `stbi__load_gif_main_outofmem` only frees possibly allocated memory in `*delays` without resetting it to zero. Thus it would be fair to say the caller of `stbi__load_gif_main` is responsible to free the allocated memory in `*delays` only if `stbi__load_gif_main` returns a non null value. However at the same time the function may return null value, but fail to free the memory in `*delays` if internally `stbi__convert_format` is called and fails. Thus the issue may lead to a memory leak if the caller chooses to free `delays` only when `stbi__load_gif_main` didn’t fail or to a double-free if the `delays` is always freed&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; nothings stb, nothings stb_image&lt;/p&gt;
&lt;p&gt;stb_image is a single file MIT licensed library for processing images.  It may look like `stbi__load_gif_main` doesn’t give guarantees about the content of output value `*delays` upon failure. Although it sets `*delays` to zero at the beginning, it doesn’t do it in case the image is not recognized as GIF and a call to `stbi__load_gif_main_outofmem` only frees possibly allocated memory in `*delays` without resetting it to zero. Thus it would be fair to say the caller of `stbi__load_gif_main` is responsible to free the allocated memory in `*delays` only if `stbi__load_gif_main` returns a non null value. However at the same time the function may return null value, but fail to free the memory in `*delays` if internally `stbi__convert_format` is called and fails. Thus the issue may lead to a memory leak if the caller chooses to free `delays` only when `stbi__load_gif_main` didn’t fail or to a double-free if the `delays` is always freed&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2023-45666</guid>
    </item>
  </channel>
</rss>
