CVE-2026-24450: 
NixOS vulnerability analysis and mitigation

CVE-2026-24450 is an integer overflow vulnerability in the uncompressed_fp_dng_load_raw function of LibRaw (Commit 8dc68e2), leading to a heap buffer overflow when processing specially crafted DNG image files. It was discovered by Francesco Benvenuto of Cisco Talos, disclosed to the vendor on February 12, 2026, patched on April 6, 2026, and publicly released on April 7, 2026. The confirmed affected version is LibRaw Commit 8dc68e2 (including version 0.22.1). The CVSSv3.1 score is 8.1 (High) per Talos, though some sources estimate up to 9.8 (Talos Report, GitHub Advisory).

The root cause is a CWE-190 (Integer Overflow or Wraparound) in src/decoders/fp_dng.cpp. The buffer size check at allocation time correctly uses 64-bit (INT64) arithmetic, but the actual calloc() call uses 32-bit arithmetic — all operands (tileCnt, tileWidth, tileHeight, ifd->samples) are 32-bit types — causing the product to overflow UINT32_MAX when attacker-controlled TIFF tag values (TileWidth, TileLength, SamplesPerPixel) are large enough. The undersized buffer is then written to using the original full dimensions, resulting in a heap buffer overflow. Exploitation requires the application to have set max_raw_memory_mb above approximately 16,384 MB (~16 GB), since the default limit of 2,048 MB prevents the overflow-triggering dimensions from reaching the vulnerable allocation path. A proof-of-concept (poc_fp_dng_overflow.cpp) was developed by Talos and crash output via AddressSanitizer is publicly documented (Talos Report).

Successful exploitation can result in heap corruption and potential arbitrary code execution on systems running vulnerable LibRaw-based applications with elevated memory limits. All three CIA triad pillars are affected: confidentiality (sensitive data exposure), integrity (arbitrary code execution), and availability (crash/denial of service). Because LibRaw is a widely embedded library used in image processing software, photo editors, and media pipelines, the blast radius extends to any application that processes untrusted DNG files with a non-default memory configuration (Talos Report, Red Hat Bugzilla).

A proof-of-concept exploit was developed by Cisco Talos and crash details are publicly documented, though no weaponized exploit kit or in-the-wild exploitation has been confirmed as of the report date. The EPSS score is approximately 0.043–0.078%, indicating a low near-term exploitation probability. The vulnerability is not in the CISA KEV catalog. Exploitation requires a non-default configuration (max_raw_memory_mb > ~16 GB), which limits the practical attack surface to specialized or misconfigured deployments (Talos Report, GitHub Advisory).

1. Craft a malicious DNG file: Create a DNG/TIFF file with attacker-controlled TIFF tags — specifically TileWidth, TileLength (or ImageWidth/RowsPerStrip for strip layout), and SamplesPerPixel — set to values where tileCnt * tileWidth * tileHeight * samples > UINT32_MAX (e.g., width=64000, height=22370, samples=3).
2. Target a vulnerable application: Identify an application that uses LibRaw Commit 8dc68e2 or version 0.22.1 and has configured max_raw_memory_mb above ~16,384 MB (16 GB). This is a non-default setting typically found in high-throughput image processing pipelines.
3. Deliver the malicious file: Provide the crafted DNG file to the target application via any supported input channel (file upload, network share, email attachment, etc.).
4. Trigger the overflow: When the application calls LibRaw::unpack() on the file, uncompressed_fp_dng_load_raw() is invoked. The 32-bit multiplication overflows, causing calloc() to allocate a much smaller buffer (~284 KB in the example) than required.
5. Achieve heap buffer overflow: During tile/strip processing, data is read from the file directly into the undersized float_raw_image buffer using the original full dimensions, writing up to 768,000 bytes per row beyond the allocated region, corrupting heap metadata and adjacent allocations.
6. Leverage heap corruption: Depending on heap layout and application context, the attacker may achieve arbitrary code execution by overwriting function pointers, vtable entries, or other heap-resident control data (Talos Report).

• File System: Presence of unusually large or malformed DNG files submitted to image processing services; files with extreme TIFF tag values (TileWidth/TileLength products exceeding ~4 billion).
• Process: Crashes or abnormal termination of LibRaw-based applications (e.g., segmentation faults, AddressSanitizer heap-buffer-overflow reports) when processing DNG files; unexpected child processes spawned from image processing daemons.
• Logs: Application crash logs referencing LibRaw::uncompressed_fp_dng_load_raw(), fp_dng.cpp, or LibRaw::unpack(); AddressSanitizer output indicating heap-buffer-overflow at libraw_datastream.cpp:339.
• Network: Unexpected inbound delivery of DNG files to services not normally receiving such content; outbound connections from image processing services to unknown external hosts following DNG file processing (Talos Report).

The vendor released a patch on April 6, 2026 (commit after 8dc68e2); users should update LibRaw to any version beyond the vulnerable commit. Red Hat has issued errata RHSA-2026:11360 (RHEL 9), RHSA-2026:13854 (RHEL 9.6 EUS), RHSA-2026:13870 (RHEL 9.4 EUS), and RHSA-2026:19345 (RHEL 9) addressing this issue. OpenSUSE security announcements have also been published. As an immediate workaround, ensure max_raw_memory_mb is kept at or below the default 2,048 MB (2 GB), which prevents the overflow-triggering dimensions from reaching the vulnerable allocation. Additionally, restrict processing of untrusted DNG files from external sources and sandbox image processing pipelines (Red Hat Bugzilla, Talos Report).

Cisco Talos published a detailed technical write-up (TALOS-2026-2363) on April 7, 2026, crediting Francesco Benvenuto as the discoverer. The Talos blog also covered this vulnerability alongside Foxit vulnerabilities in a combined post. The vulnerability was discussed on oss-security mailing lists and noted on social media platforms including Mastodon. Linux distribution maintainers (Red Hat, openSUSE, Fedora, AlmaLinux, Oracle Linux) responded promptly with security updates (Talos Blog, oss-sec).