<?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>Mon, 12 Oct 2026 23:06:13 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-48072 — OpenEXR's Inaccurate Pointer Arithmetic can Cause an Out of Bounds Heap</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-48072</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AcademySoftwareFoundation openexr&lt;/p&gt;
&lt;p&gt;OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. Version 3.3.2 is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. This is fixed in version 3.3.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AcademySoftwareFoundation openexr&lt;/p&gt;
&lt;p&gt;OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. Version 3.3.2 is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. This is fixed in version 3.3.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-48072</guid>
    </item>
    <item>
      <title>GHSA-4r7w-q3jg-ff43 — OpenEXR Out of Bounds Heap Read due to Bad Pointer Arithmetic in LossyDctDecoder_execute</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-4r7w-q3jg-ff43</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: OpenEXR&lt;/p&gt;
&lt;p&gt;### Summary
The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In the `LossyDctDecoder_execute` function (from `src/lib/OpenEXRCore/internal_dwa_decoder.h`, when SSE2 is enabled), the following code is used to copy data from the chunks:&lt;/p&gt;
&lt;p&gt;```cpp
// no-op conversion to linear
for (int y = 8 * blocky; y &amp;lt; 8 * blocky + maxY; ++y)
{
    __m128i* restrict dst = (__m128i *) chanData[comp]-&amp;gt;_rows[y];
    __m128i const * restrict src = (__m128i const *)&amp;amp;rowBlock[comp][(y &amp;amp; 0x7) * 8];&lt;/p&gt;
&lt;p&gt;for (int blockx = 0; blockx &amp;lt; numFullBlocksX; ++blockx)
    {
        _mm_storeu_si128 (dst, _mm_loadu_si128 (src)); //&lt;/p&gt;
&lt;p&gt;src += 8 * 8; // &amp;lt;--- si128 pointer incremented as a uint16_t
        dst += 8;
    }
}
```&lt;/p&gt;
&lt;p&gt;The issue arises because the `src` pointer, which is a `si128` pointer, is incremented by `8*8`, as if it were a `uint16_t` pointer (64 * uint16_t == 128 bytes). In non-block aligned chunks (width/height not a multiple of 8), this can cause `src` to point past the boundaries of the chunk.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;In order to reproduce the PoC with fidelity and avoid undefined behaviors, it is necessary to enable ASAN (and SSE2). Otherwise the out-of-bound read will not be detected until its side-effect causes a crash.&lt;/p&gt;
&lt;p&gt;NOTE: please download the `dwadecoder_crash.exr` file from the following link:&lt;/p&gt;
&lt;p&gt;https://github.com/ShielderSec/poc/tree…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: OpenEXR&lt;/p&gt;
&lt;p&gt;### Summary
The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In the `LossyDctDecoder_execute` function (from `src/lib/OpenEXRCore/internal_dwa_decoder.h`, when SSE2 is enabled), the following code is used to copy data from the chunks:&lt;/p&gt;
&lt;p&gt;```cpp
// no-op conversion to linear
for (int y = 8 * blocky; y &amp;lt; 8 * blocky + maxY; ++y)
{
    __m128i* restrict dst = (__m128i *) chanData[comp]-&amp;gt;_rows[y];
    __m128i const * restrict src = (__m128i const *)&amp;amp;rowBlock[comp][(y &amp;amp; 0x7) * 8];&lt;/p&gt;
&lt;p&gt;for (int blockx = 0; blockx &amp;lt; numFullBlocksX; ++blockx)
    {
        _mm_storeu_si128 (dst, _mm_loadu_si128 (src)); //&lt;/p&gt;
&lt;p&gt;src += 8 * 8; // &amp;lt;--- si128 pointer incremented as a uint16_t
        dst += 8;
    }
}
```&lt;/p&gt;
&lt;p&gt;The issue arises because the `src` pointer, which is a `si128` pointer, is incremented by `8*8`, as if it were a `uint16_t` pointer (64 * uint16_t == 128 bytes). In non-block aligned chunks (width/height not a multiple of 8), this can cause `src` to point past the boundaries of the chunk.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;In order to reproduce the PoC with fidelity and avoid undefined behaviors, it is necessary to enable ASAN (and SSE2). Otherwise the out-of-bound read will not be detected until its side-effect causes a crash.&lt;/p&gt;
&lt;p&gt;NOTE: please download the `dwadecoder_crash.exr` file from the following link:&lt;/p&gt;
&lt;p&gt;https://github.com/ShielderSec/poc/tree…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-4r7w-q3jg-ff43</guid>
    </item>
  </channel>
</rss>
