<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
	<DocumentTitle xml:lang="en">An update for OpenEXR is now available for openEuler-22.03-LTS-SP4</DocumentTitle>
	<DocumentType>Security Advisory</DocumentType>
	<DocumentPublisher Type="Vendor">
		<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
		<IssuingAuthority>openEuler security committee</IssuingAuthority>
	</DocumentPublisher>
	<DocumentTracking>
		<Identification>
			<ID>openEuler-SA-2026-1844</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2026-04-11</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2026-04-11</InitialReleaseDate>
		<CurrentReleaseDate>2026-04-11</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler SA Tool V1.0</Engine>
			<Date>2026-04-11</Date>
		</Generator>
	</DocumentTracking>
	<DocumentNotes>
		<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">OpenEXR security update</Note>
		<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for OpenEXR is now available for openEuler-22.03-LTS-SP4</Note>
		<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light &amp;amp; Magic for use in computer imaging applications.

Security Fix(es):

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two&apos;s-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34380)

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34589)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for OpenEXR is now available for openEuler-22.03-LTS-SP4.

openEuler Security has rated this update as having a security impact of medium. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
		<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">Medium</Note>
		<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">OpenEXR</Note>
	</DocumentNotes>
	<DocumentReferences>
		<Reference Type="Self">
			<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1844</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-34380</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-34589</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-34380</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2026-34589</URL>
		</Reference>
	</DocumentReferences>
	<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-22.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">openEuler-22.03-LTS-SP4</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="OpenEXR-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-3.1.5-6.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-debuginfo-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-debuginfo-3.1.5-6.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-debugsource-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-debugsource-3.1.5-6.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-devel-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-devel-3.1.5-6.oe2203sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-libs-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-libs-3.1.5-6.oe2203sp4.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="OpenEXR-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-3.1.5-6.oe2203sp4.src.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="OpenEXR-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-3.1.5-6.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-debuginfo-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-debuginfo-3.1.5-6.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-debugsource-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-debugsource-3.1.5-6.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-devel-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-devel-3.1.5-6.oe2203sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="OpenEXR-libs-3.1.5-6" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">OpenEXR-libs-3.1.5-6.oe2203sp4.x86_64.rpm</FullProductName>
		</Branch>
	</ProductTree>
	<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two&apos;s-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.</Note>
		</Notes>
		<ReleaseDate>2026-04-11</ReleaseDate>
		<CVE>CVE-2026-34380</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.9</BaseScore>
				<Vector>AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>OpenEXR security update</Description>
				<DATE>2026-04-11</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1844</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.</Note>
		</Notes>
		<ReleaseDate>2026-04-11</ReleaseDate>
		<CVE>CVE-2026-34589</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.0</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>OpenEXR security update</Description>
				<DATE>2026-04-11</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1844</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>