CVE-2026-34379: 
NixOS vulnerability analysis and mitigation

CVE-2026-34379 is a misaligned memory write vulnerability in OpenEXR's LossyDctDecoder_execute() function that can cause denial of service and potential memory corruption when decoding DWA or DWAB-compressed EXR files containing FLOAT-type channels. It affects OpenEXR versions 3.2.0–3.2.6, 3.3.0–3.3.8, and 3.4.0–3.4.8. The vulnerability was published on April 6, 2026, and patched the same day with releases 3.2.7, 3.3.9, and 3.4.9. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, Red Hat).

The root cause is an incorrect type conversion (CWE-704 / CWE-843) in src/lib/OpenEXRCore/internal_dwa_decoder.h at line 749, where the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer directly to float * and writing through it. Because DwaCompressor_uncompress() slices the output buffer sequentially per channel without adding alignment padding, a FLOAT channel following a HALF channel (or any channel whose total byte size is not a multiple of 4) receives a _rows[y] pointer that is not 4-byte aligned. This constitutes undefined behavior (CWE-787, CWE-475) under the C standard: on ARM, RISC-V, and MIPS architectures it causes an immediate bus error/crash, while on x86 the hardware tolerates the access but compiler auto-vectorization (SSE/AVX) may generate incorrect code, potentially leading to memory corruption. The fix replaces the direct pointer dereference with a memcpy-based unaligned_store32() helper, consistent with patterns already used elsewhere in the codebase (GitHub Advisory, Red Hat Bugzilla).

The primary impact is a reliable denial of service: any application using OpenEXRCore to decode untrusted EXR files with DWA/DWAB compression and FLOAT-type channels will crash immediately on alignment-enforcing architectures (ARM, RISC-V, MIPS). On x86, the misaligned write succeeds at the hardware level but may cause silent data corruption or, in the presence of compiler auto-vectorization (SSE/AVX), potentially exploitable memory corruption. Confidentiality impact is rated None, integrity impact is Low (due to possible data corruption), and availability impact is High (GitHub Advisory).

1. Craft a malicious EXR file: Create a DWA or DWAB-compressed EXR file containing at least one HALF-type channel followed by a FLOAT-type channel, ensuring the FLOAT channel's row buffer pointer will not be 4-byte aligned after sequential buffer slicing.
2. Deliver the file to the target: Distribute the crafted .exr file via email attachment, web upload, shared network storage, or any other vector that causes a vulnerable application (e.g., image viewer, VFX pipeline tool, media processor) to open and decode it.
3. Trigger decoding: The victim application calls exr_decoding_run() → exr_uncompress_chunk() → internal_exr_undo_dwab() → DwaCompressor_uncompress() → LossyDctDecoder_execute().
4. Trigger the misaligned write: At internal_dwa_decoder.h:749, the decoder casts the unaligned uint8_t * row pointer to float * and writes a converted FLOAT value through it, triggering undefined behavior.
5. Achieve denial of service: On ARM/RISC-V/MIPS, the process crashes immediately with a bus error. On x86 with UBSan or in auto-vectorized builds, the crash or memory corruption is triggered, causing application termination or potentially exploitable state (GitHub Advisory).

• Process: Unexpected crash or SIGBUS signal in any process loading OpenEXR libraries (e.g., image viewers, VFX tools, media servers) when processing .exr files.
• Logs: UBSan runtime error messages referencing internal_dwa_decoder.h:749 such as runtime error: store to misaligned address ... for type 'float', which requires 4 byte alignment; ASAN stack traces showing LossyDctDecoder_execute → DwaCompressor_uncompress → internal_exr_undo_dwab → exr_uncompress_chunk → exr_decoding_run.
• File System: Presence of unexpected or externally sourced .exr files with DWA/DWAB compression in directories processed by vulnerable applications.
• Network: Unusual inbound file transfers of .exr files to systems running OpenEXR-dependent applications, particularly from untrusted external sources (GitHub Advisory).

Upgrade OpenEXR to the patched versions: 3.2.7, 3.3.9, or 3.4.9 depending on your current version branch (OpenEXR v3.2.7, OpenEXR v3.3.9, OpenEXR v3.4.9). As a workaround prior to patching, restrict processing of EXR files to trusted sources only and implement file format validation before parsing. Downstream Linux distributions including openSUSE and Fedora have issued updated packages; users of those distributions should apply available OS-level updates (Red Hat).

Red Hat tracked the vulnerability as high severity in their Bugzilla system and issued a CVE advisory shortly after disclosure (Red Hat, Red Hat Bugzilla). OpenSUSE and Fedora issued security announcements and updated packages for their respective distributions. The vulnerability was detected by multiple commercial scanners including Nessus and Qualys, indicating broad uptake in enterprise vulnerability management programs.