제출 #864839: MZ Automation libiec61850 1.6.1+ Memory Corruption(heap use-after-free)

A heap use-after-free vulnerability exists in the MMS file service implementation of libiec61850 in the v1.6_develop branch, validated on commit 196bb76db9a560b92fc12284c10da7720920b164. The issue is reachable through a real protocol path exposed by the library itself and can be reproduced with the official example programs. In the tested environment, the vulnerable path is triggered when the server-side file service handles an ObtainFile/set-file style transfer and the client connection is terminated while the asynchronous upload task is still active.

The root cause is an object lifetime mismatch between the per-transfer file upload task and the underlying MmsServerConnection object. During ObtainFile processing, the server creates an MmsObtainFileTask and stores a raw pointer to the current MmsServerConnection in task->connection. When the client disconnects unexpectedly, the cleanup path in mmsServerConnection_stopFileUploadTasks does not fully detach the task from the connection object. Instead, it only changes the task state to MMS_FILE_UPLOAD_STATE_INTERRUPTED. The stale task->connection pointer remains unchanged. Shortly afterwards, the normal connection teardown path destroys the associated MmsServerConnection object in MmsServerConnection_destroy and frees the heap memory previously allocated in MmsServerConnection_init. This leaves the background upload task with a dangling pointer to already freed connection state.

The vulnerability becomes exploitable because the background task processing routine later revisits that interrupted upload task and dereferences task->connection before the task reaches its safe cleanup branch. In mmsServer_fileUploadTask, the code reads task->connection->isoConnection at function entry, before the state-specific interrupted-task cleanup resets the task to an unused state. As a result, a stale pointer left behind by the disconnect path is dereferenced after the MmsServerConnection object has already been freed. This is a classic cleanup-order and lifetime-management flaw in an asynchronous state machine, not merely a null-pointer dereference or an example-level misuse.

The bug can be reproduced with the official server and client examples that exercise the MMS file service. A build with AddressSanitizer and UndefinedBehaviorSanitizer is sufficient. The server example server_example_files is started with a writable filestore. The client example file-tool is then used to upload a large file with the set operation. By forcibly terminating the client during the transfer, the server closes the connection while the file upload task is still pending. In the observed reproduction, the client output confirms that file-tool entered the set big.bin path and was killed during transfer. The server output shows “Connection opened”, a fileAccessHandler invocation for service 2 on big.bin, then “Connection closed”, immediately followed by an AddressSanitizer report.

The ASan report clearly identifies the crash as a heap-use-after-free in mmsServer_fileUploadTask at src/mms/iso_mms/server/mms_file_service.c:487, where task->connection is dereferenced. The same report shows that the accessed object was freed in MmsServerConnection_destroy at src/mms/iso_mms/server/mms_server_connection.c:848 and had originally been allocated in MmsServerConnection_init at src/mms/iso_mms/server/mms_server_connection.c:802. The backtrace further shows that the fault is reached through the normal single-threaded server event loop: MmsServer_handleBackgroundTasks, processPeriodicTasks, IedServer_performPeriodicTasks, and singleThreadedServerThread. This demonstrates that the defect is in the library’s internal task/connection lifecycle management, not in external application code.

From a security perspective, the vulnerability allows a remote peer to crash the server process by establishing a legitimate MMS file transfer and aborting the connection at a carefully chosen time while the upload task is still active. The minimum verified impact is a remotely triggerable denial of service affecting applications that expose the vulnerable file service path. Because the fault is a real heap use-after-free on a live server-side code path, memory corruption occurs inside the library itself. Although the current proof demonstrates reliable process termination, use-after-free conditions are generally security-relevant beyond simple availability loss and therefore warrant coordinated disclosure and a formal identifier.

The affected code is part of the library core rather than merely example-specific logic. The examples only provide a straightforward way to expose and reproduce the issue. The actual flaw lies in the MMS file service and connection teardown interaction inside src/mms/iso_mms/server/mms_file_service.c and src/mms/iso_mms/server/mms_server_connection.c. In particular, the disconnect handler marks file upload tasks as interrupted without nulling the retained connection pointer, while the later background-task handler dereferences that retained pointer before performing interrupted-state cleanup. Any deployment that enables the relevant MMS file service functionality and permits a remote client to reach this transfer path may therefore be affected.

In summary, this issue should be classified as a remotely reachable heap use-after-free in the libiec61850 MMS file upload/ObtainFile handling path. It is reproducible with official example binaries, backed by allocator and free-site evidence from AddressSanitizer, and caused by a stale MmsServerConnection pointer retained in an asynchronous file upload task after disconnect and object destruction.

• 원천: ⚠️ https://github.com/mz-automation/libiec61850/issues/597
• 사용자: SCU_1CP (UID 99172)
• 제출: 2026. 06. 21. PM 01:25 (2 개월 ago)
• 모더레이션: 2026. 08. 07. AM 10:07 (2 months later)
• 상태: 중복
• VulDB 항목: 385410 [mz-automation libiec61850 까지 1.6.1 MMS ObtainFile Task mms_file_service.c fileHandle 메모리 손상]
• 포인트들: 0