Description

A heap-based buffer overflow vulnerability exists in the Dia diagram editor WPG file format importer. In plug-ins/wpg/wpg-import.c, the WPG import renderer allocates a fixed palette with: ren->pPal = g_new0(WPGColorRGB, 256); When handling a WPG_COLORMAP record, the parser reads a start index (i16) and number of colors (iNum16) from the file and reads palette data with: bRet &= (iNum16 == (int)fread(&ren->pPal[i16], sizeof(WPGColorRGB), iNum16, f)); The only bounds-related check is `if (i16 >= 0 && i16 <= iSize)`, where iSize is the WPG record size—not the palette capacity. There is no validation that i16 is less than 256 or that i16 + iNum16 does not exceed 256. A malicious WPG file can supply i16=256 and iNum16=264. That causes fread() to write 792 bytes starting at &pPal[256], while the palette buffer is only 768 bytes (256 entries × 3 bytes). This overflows into adjacent heap metadata and can crash Dia (SIGABRT / malloc corruption errors) or, depending on heap layout and exploit primitives, potentially lead to arbitrary code execution. Exploitation requires convincing a user to open a crafted WPG file via Dia's file dialog, command line, or file association. No special privileges are required to deliver the file to the victim. Affected component: WPG parser (plug-ins/wpg/wpg-import.c). Affected versions: all Dia versions containing this code path (reporter tested Dia 0.98+git20260221-1; issue present on upstream master as of 2026-08-21).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T20:18:02.160Z",
  "pubdate": "2026-08-26T20:18:02.160Z",
  "executiveSummary": "A heap-based buffer overflow vulnerability exists within the WPG file format importer of the Dia diagram editor. The vulnerability stems from improper bounds validation during the parsing of WPG_COLORMAP records, which allows an attacker-controlled index and count to exceed the allocated palette buffer size.\nThe vulnerability affects all versions of Dia containing the vulnerable code path in plug-ins/wpg/wpg-import.c, including versions up to 0.98+git20260221-1 and the upstream master branch as of 2026-08-21.\nSuccessful exploitation can lead to heap memory corruption, causing application crashes (SIGABRT) or potentially enabling arbitrary code execution. The attack requires user interaction, specifically convincing a target to open a maliciously crafted WPG file via the file dialog, command line, or file association. No specific privileges or network connectivity are required for the attacker, making this a significant threat to local users processing untrusted diagram files.",
  "technicalDetails": "The root cause of this vulnerability is an insufficient bounds check within the WPG parser's implementation in plug-ins/wpg/wpg-import.c. The renderer allocates a fixed-size heap buffer, ren->pPal, designed to hold 256 WPGColorRGB structures using g_new0(WPGColorRGB, 256).\nWhen processing a WPG_COLORMAP record, the parser retrieves a starting index (i16) and a number of colors (iNum16) directly from the input file. The existing validation logic only verifies that i16 is within the range [0, iSize], where iSize represents the WPG record size rather than the capacity of the palette buffer. Crucially, the code fails to verify that i16 < 256 or that the sum of i16 + iNum16 remains within the 256-entry boundary of the pPal buffer.\nThe implementation proceeds to read data from the file directly into the heap-allocated buffer using: bRet &= (iNum16 == (int)fread(&ren->pPal[i16], sizeof(WPGColorRGB), iNum16, f)).\nAn attacker can exploit this by providing a crafted WPG file containing an i16 value of 256 and an iNum16 value of 264. This forces the fread function to write 792 bytes to the heap starting at an offset beyond the valid buffer (which is only 768 bytes in total capacity).\nThis out-of-bounds write corrupts adjacent heap metadata, such as chunk headers or other object pointers managed by the memory allocator. Depending on the specific state of the heap at the time of execution, this corruption can lead to a controlled crash via a SIGABRT during memory management operations (e.g., free() or malloc()) or provide an exploitation primitive for arbitrary code execution if the attacker can influence the heap layout to overwrite sensitive control structures or function pointers.\nBecause the parser does not perform authentication or require high privileges, the attack vector is purely based on the victim interacting with the malicious file. The lack of robust input validation during the file import process effectively elevates a malformed file into a weaponized binary payload capable of compromising the host process."
}