Gửi #864520: MZ Automation libiec61850 1.6.1 Memory Corruption(heap-use-after-free)

libiec61850 version 1.6.1 contains a server-side heap use-after-free in the report control / dynamic dataset handling path. The issue can be triggered when an association-specific dataset is created by one MMS client connection, bound to a URCB as DatSet=@name, and the owning connection is then closed before another connection reuses or re-enables the same report control block. Under this condition, the server retains stale dataset metadata inside the URCB runtime state and later dereferences a freed heap string during dataset validation, causing a crash of the server process.

The vulnerability is rooted in inconsistent ownership and lifetime management between connection-scoped named variable lists and the longer-lived report control state. In the affected implementation, a client can create an association-specific named variable list through the MMS named variable list service. The named variable list name is allocated on the heap when the list is created. Later, when a URCB is configured with DatSet=@ds1, the report handling code resolves the association-specific named variable list for the current connection and converts it into a runtime dataset object used by the report control instance. The report control block then stores this dataset in its internal rc->dataSet field for subsequent report processing and validation.

The flaw appears when the connection that created and owns the association-specific named variable list is closed. During connection teardown, the server destroys the connection-specific named variable lists and frees the associated heap-allocated name string. However, the URCB runtime state is not synchronously detached from this connection-owned dataset metadata. As a result, rc->dataSet can continue to reference strings and entries that conceptually originated from the destroyed named variable list. A later client connection operating on the same URCB can trigger the stale state. When the server processes the next DatSet validation or report enable sequence, updateReportDataset compares the previous dataset name with the newly supplied dataset name using strcmp. At that point, rc->dataSet->name may still point to memory that has already been freed during the earlier connection cleanup. This leads to a heap use-after-free in the server.

The issue is therefore not a simple bounds-checking bug. It is a lifecycle and ownership error caused by shallow aliasing of connection-scoped dataset metadata into a longer-lived report control structure. In practical terms, the flaw can be described as an ownership confusion and lifetime mismatch between the association-specific MmsNamedVariableList and the report control’s runtime dataset cache. The first connection effectively “arms” the stale state by creating and binding the dynamic dataset, while the second connection “triggers” the fault by interacting with the same URCB after the original connection has been closed.

The affected execution path is visible in the protocol implementation. The server creates the association-specific named variable list through the MMS DefineNamedVariableList service. The list name is heap-allocated during MmsNamedVariableList_create. The report control path later resolves DatSet=@name in updateReportDataset and maps the connection-local named variable list into a dataset object stored in rc->dataSet. When the connection is destroyed, MmsServerConnection_destroy releases the connection-local named variable lists through MmsNamedVariableList_destroy, including the heap string that held the dataset name. The stale pointer is then reused when a later write to the URCB causes updateReportDataset to compare rc->dataSet->name against the new dataset string.

This behavior has been reproduced on the official server_example_basic_io program from libiec61850 1.6.1. A minimal client PoC first creates an association-specific dataset and assigns it to a URCB, then closes the connection. A second client connection subsequently reserves or enables the same report control block and causes the server to revalidate the dataset state. In the reproduced crash, AddressSanitizer reports a heap-use-after-free in strcmp called from updateReportDataset in reporting.c. The freed memory is traced back to MmsNamedVariableList_destroy during MmsServerConnection_destroy, and the allocation is traced back to StringUtils_copyString during MmsNamedVariableList_create. This establishes a direct allocate-free-use chain for the same heap object and confirms that the crash is caused by a genuine stale pointer dereference in the server.

The direct security impact is denial of service. A remote client that can reach the MMS/IEC 61850 service and perform the relevant dataset and report control operations can crash the server process by issuing a crafted but protocol-valid sequence of actions across two connections. Because the bug is a heap use-after-free in a network-facing server implementation, it also represents a broader memory-safety weakness; however, the demonstrated and verified impact is server crash / service interruption rather than proven code execution. In IEC 61850 deployments, such a crash can interrupt reporting functionality, disturb telemetry or event delivery, and temporarily impair monitoring or supervisory functions that rely on the affected server.

In summary, the vulnerability is a server-side heap use-after-free caused by retention of stale dynamic dataset metadata across connection teardown. The flaw is triggered when an association-specific dataset created by one connection is bound to a URCB, the owning connection is closed and its named variable list is destroyed, and a later connection reuses the same URCB so that updateReportDataset dereferences the freed dataset name. The issue is independently reproducible on the official example server and is suitable for security classification as CWE-416 (Use After Free). And CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H(7.5/high)

• Nguồn: ⚠️ https://github.com/mz-automation/libiec61850/issues/596
• Người dùng: VULL (UID 98817)
• Đệ trình: 20/06/2026 17:31 (cách đây 2 các tháng)
• Kiểm duyệt: 06/08/2026 15:58 (2 months later)
• Trạng thái: được chấp nhận
• Mục VulDB: 386569 [MZ Automation libiec61850 đến 1.6.1 URCB Revalidation reporting.c deleteDataSetValuesShadowBuffer tràn bộ đệm]
• điểm: 20