Description

A stack-based buffer overflow vulnerability exists in the Dia diagram editor when processing Network Bus objects from Dia XML project files. In objects/network/bus.c, bus_load() reads the number of bus handles from the file attribute "bus_handles" using attribute_num_data() without validating an upper bound: bus->num_handles = attribute_num_data(attr); When a bus handle is subsequently moved, bus_handle_moved() allocates two temporary arrays on the stack: parallel = (real *)g_alloca(num_handles * sizeof(real)); perp = (real *)g_alloca(num_handles * sizeof(real)); Because num_handles is fully attacker-controlled via the project file, sufficiently large values (for example 262144 or higher) cause g_alloca() to consume more stack space than the default thread stack limit (typically 8 MB on Linux), resulting in stack overflow, SIGSEGV, and potential stack frame / return-address corruption. An attacker can embed a Bus object with an excessive bus_handles count in a malicious .dia file. Exploitation requires the victim to open the file in Dia (file dialog, command line, or file association) and trigger handle manipulation (moving a bus handle), which exercises the vulnerable code path. The identical g_alloca pattern is present in objects/Misc/tree.c (copied from bus.c) and is likely vulnerable to the same class of attack via Tree objects. Affected versions: Dia 0.98.0 and earlier versions containing this code; issue confirmed on upstream master as of 2026-08-21. Upstream report: https://gitlab.gnome.org/GNOME/dia/-/issues/581

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T13:19:22.043Z",
  "pubdate": "2026-08-26T13:19:22.043Z",
  "executiveSummary": "A stack-based buffer overflow vulnerability exists in the Dia diagram editor, specifically within the processing of Network Bus and Tree objects in Dia XML project files. The vulnerability stems from the application failing to validate an upper bound for the 'bus_handles' attribute during file parsing, allowing an attacker to supply an arbitrarily large integer.\nWhen a user opens a malicious .dia file and triggers a handle manipulation event, the application utilizes the attacker-controlled value to allocate memory on the stack via g_alloca(). Supplying a sufficiently large value causes stack exhaustion, leading to a SIGSEGV or potential stack frame and return-address corruption.\nThis vulnerability affects Dia 0.98.0 and earlier versions. Exploitation requires user interaction, specifically opening a crafted file and interacting with the vulnerable object type. The impact ranges from application crashes (Denial of Service) to potential arbitrary code execution depending on the attacker's ability to manipulate the stack layout. The risk is elevated as the same vulnerable pattern exists in both the Network Bus and Tree object implementations.",
  "technicalDetails": "The root cause of this vulnerability is improper input validation within the Dia file parsing mechanism. In objects/network/bus.c, the bus_load() function reads the 'bus_handles' attribute directly from the XML project file via attribute_num_data(attr) and assigns this value to the bus->num_handles member variable without verifying if the value exceeds a reasonable memory limit or a defined object maximum.\nThe vulnerability is triggered during the execution of bus_handle_moved(). This function invokes g_alloca() to allocate temporary arrays ('parallel' and 'perp') on the process stack based on the value of num_handles. Because g_alloca() allocates memory directly on the stack rather than the heap, an attacker-supplied value (e.g., 262144 or greater) forces the stack pointer to increment beyond the allocated stack segment (typically 8 MB on Linux systems).\nThe exploitation flow proceeds as follows: First, an attacker crafts a malicious .dia file containing a Network Bus or Tree object with an excessively large 'bus_handles' integer. Second, the victim opens this file using the Dia application. Third, the victim performs an action that triggers the bus_handle_moved() function (or the analogous function in objects/Misc/tree.c). Fourth, the subsequent call to g_alloca() induces a stack overflow. If the stack exhaustion occurs, the program terminates with a SIGSEGV (Denial of Service). In scenarios where the overflow allows for controlled overwriting of adjacent stack frames, an attacker may attempt to hijack the instruction pointer by overwriting the function's return address.\nThe vulnerability is confirmed present in upstream master as of 2026-08-21. The use of g_alloca() is inherently dangerous when the allocation size is derived from untrusted input, as there is no mechanism to catch allocation failures; when the stack space is exceeded, the process terminates immediately rather than returning a null pointer as malloc() would. The same pattern is replicated in objects/Misc/tree.c, suggesting that Tree objects provide a secondary attack vector for the same class of vulnerability."
}