## Summary A **server-side heap-buffer-overflow read** can be triggered in **S2OPC 1.7.3** during `RepublishResponse` serialization. The bug is caused by an internal **cardinality mismatch** in `OpcUa_NotificationMessage` reconstruction on the server: - the normal `Publish` path can legitimately produce `NotificationMessage.NoOfNotificationData == 2` when the same notification message contains both a `DataChangeNotification` and an `EventNotificationList`; - the `RepublishResponse` construction path preserves that logical count, but reallocates `NotificationData` for **only one** `SOPC_ExtensionObject` and deep-copies only element `0`; - the generic encoder later trusts `NoOfNotificationData == 2` and iterates past the single allocated element, causing an out-of-bounds heap read while serializing the response. This issue is reachable through a **real OPC UA server execution path** using the official validation server (`toolkit_test_server events`) with event management enabled. The currently demonstrated impact is a **reliable remote server crash / denial of service**. --- ## Version - **Affected version**: `S2OPC_Toolkit_1.7.3` - **Verified commit**: `b4c5c7d63cd69698461d514b905a7c92b3c377c4` --- ## Impact ### Confirmed security impact A remote client can drive the server into a state where it serializes a malformed `RepublishResponse` object and performs an **out-of-bounds heap read** in `SOPC_ExtensionObject_Write`, leading to a **stable server-side crash** under AddressSanitizer. ### Security significance This is not a parser-only or unit-test-only issue. The vulnerable state is created by the server itself across a legitimate: 1. `CreateSubscription` 2. `CreateMonitoredItems` 3. `Publish` 4. `Republish` interaction chain. The demonstrated impact is **Availability: High** (remote denial of service). The primitive is an internal memory-safety violation in server response generation. In non-ASan builds, behavior is undefined once the encoder reads beyond the single allocated `SOPC_ExtensionObject` backing store. --- ## Affected path ### Runtime path - official server: `tests/ClientServer/validation_tests/server/toolkit_test_server.c` - republish handling: `src/ClientServer/services/bgenc/subscription_mgr.c` - republish response construction: `src/ClientServer/services/b2c/msg_subscription_publish_ack_bs.c` - normal mixed-notification creation: `src/ClientServer/services/b2c/msg_subscription_publish_bs.c` - final encoding crash point: `src/Common/opcua_types/sopc_encoder.c` ### Key functions - `msg_subscription_publish_bs__alloc_notification_message_items()` - `msg_subscription_publish_ack_bs__setall_msg_republish_response()` - `SOPC_ExtensionObject_Write()` --- ## Root cause ### 1. The normal `Publish` path can legitimately build a 2-element `NotificationData` array In `src/ClientServer/services/b2c/msg_subscription_publish_bs.c`, the server prepares an `OpcUa_NotificationMessage` for a `PublishResponse`. The relevant logic is: ```c notifMsg->PublishTime = SOPC_Time_GetCurrentTimeUTC(); notifMsg->NoOfNotificationData = 1; bool hasData = msg_subscription_publish_bs__p_nb_data_notifications > 0; bool hasEvent = msg_subscription_publish_bs__p_nb_event_notifications > 0; if (hasData && hasEvent) { // 1 for each type notifMsg->NoOfNotificationData = 2; } ... notifMsg->NotificationData = SOPC_Calloc((size_t) notifMsg->NoOfNotificationData, sizeof(SOPC_ExtensionObject)); ... for (int32_t i = 0; i < notifMsg->NoOfNotificationData; i++) { SOPC_ExtensionObject* notifData = &notifMsg->NotificationData[i]; SOPC_ExtensionObject_Initialize(notifData); if (dataToSet) { status = SOPC_ExtensionObject_CreateObject( notifData, &OpcUa_DataChangeNotification_EncodeableType, (void**) &dataChangeNotif); dataToSet = false; } else if (eventToSet) { status = SOPC_ExtensionObject_CreateObject( notifData, &OpcUa_EventNotificationList_EncodeableType, (void**) &eventNotifList); eventToSet = false; } } ``` This is expected behavior: if both data-change notifications and event notifications are pending in the same publish cycle, the server **intentionally** creates a 2-element `NotificationData` array. The same file later also explicitly handles the event notification at index `1` when `NoOfNotificationData == 2`, which confirms that a mixed `[DataChangeNotification, EventNotificationList]` layout is part of the intended design. ### 2. The `RepublishResponse` path preserves the count but shrinks the backing store to one element In `src/ClientServer/services/b2c/msg_subscription_publish_ack_bs.c`, the function `msg_subscription_publish_ack_bs__setall_msg_republish_response()` reconstructs the notification message for the republish response. The vulnerable code is: ```c resp->NotificationMessage = *msg_subscription_publish_ack_bs__p_notifMsg; /* Shallow copy */ resp->NotificationMessage.NotificationData = SOPC_Malloc(1 * sizeof(SOPC_ExtensionObject)); /* Deep copy for notification data */ if (resp->NotificationMessage.NotificationData == NULL) { return; } SOPC_ExtensionObject_Initialize(resp->NotificationMessage.NotificationData); if (SOPC_ExtensionObject_Copy(resp->NotificationMessage.NotificationData, msg_subscription_publish_ack_bs__p_notifMsg->NotificationData) != SOPC_STATUS_OK) { SOPC_Logger_TraceError( SOPC_LOG_MODULE_CLIENTSERVER, "msg_subscription_publish_ack_bs__setall_msg_republish_response: SOPC_ExtensionObject_Copy failure"); return; } ``` This creates the bug in two steps: 1. `resp->NotificationMessage = *msg_subscription_publish_ack_bs__p_notifMsg;` performs a **shallow copy** of the whole `NotificationMessage`, preserving: - `SequenceNumber` - `PublishTime` - `NoOfNotificationData` - the original `NotificationData` pointer 2. The code then replaces `NotificationData` with a newly allocated buffer sized for **exactly one** `SOPC_ExtensionObject`, and deep-copies only the **first** source element. As a result, for a source notification message that legitimately contains two elements, the response object becomes internally inconsistent: - `resp->NotificationMessage.NoOfNotificationData == 2` - `resp->NotificationMessage.NotificationData` points to a heap buffer containing **1** element This is the core invariant violation. ### 3. The encoder later trusts the logical count and reads past the allocated heap object When the server serializes the republish response, the generic array encoding logic trusts the object state and iterates according to `NoOfNotificationData`. At the crash point in `src/Common/opcua_types/sopc_encoder.c`, the encoder reads the `Encoding` field of the current `SOPC_ExtensionObject`: ```c encodingByte = (SOPC_Byte) extObj->Encoding; ``` That access is valid for element `0`, but invalid for element `1` because the republish response backing store contains only one allocated `SOPC_ExtensionObject`. In the reproduced run: - `sizeof(SOPC_ExtensionObject) = 72` - `offsetof(SOPC_ExtensionObject, Encoding) = 48` - newly allocated republish buffer base = `0x5070000c38b0` - invalid read for element `1` targets `0x5070000c38b0 + 72 + 48 = 0x5070000c3928` This exactly matches the ASan report. --- ## PoC Client [PoC.zip](https://github.com/user-attachments/files/29672228/PoC.zip) --- ## Reproduction ### Environment Repository/version used for verification: - repository: `https://github.com/systerel/S2OPC` - version: `S2OPC_Toolkit_1.7.3` - runtime commit: `b4c5c7d63cd69698461d514b905a7c92b3c377c4` ### Build ```bash cmake -S . -B build-asan-event \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DCMAKE_MODULE_PATH=/tmp/cmake-modules \ -DS2OPC_CLIENTSERVER_ONLY=ON \ -DENABLE_TESTING=ON \ -DENABLE_SAMPLES=ON \ -DWITH_ASAN=ON \ -DWARNINGS_AS_ERRORS=OFF \ -DS2OPC_EVENT_MANAGEMENT=ON cmake --build build-asan-event -j 8 \ --target toolkit_test_server toolkit_test_client_republish ``` If the decrypted client key is missing: ```bash openssl pkey \ -in S2OPC/build-asan-event/bin/client_private/encrypted_client_2k_key.pem \ -passin pass:password \ -out S2OPC/build-asan-event/bin/client_private/client_2k_key.pem ``` ### Run the official server ```bash cd S2OPC/build-asan-event/bin env TEST_PASSWORD_PRIVATE_KEY=password ./toolkit_test_server events ``` Expected startup banner: ```bash S2OPC_Common - Version: 1.7.3, SrcCommit: b4c5c7d63cd69698461d514b905a7c92b3c377c4*, DockerId: , BuildDate: 2026-06-25 S2OPC_ClientServer - Version: 1.7.3, SrcCommit: b4c5c7d63cd69698461d514b905a7c92b3c377c4*, DockerId: , BuildDate: 2026-06-25 <Test_Server_Toolkit: initialized <Test_Server_Toolkit: Certificates and key loaded <Test_Server_Toolkit: @ space configured <Demo_Server: Server started ``` ### Run the minimal reproducer client A minimal local harness was added as: - `tests/ClientServer/validation_tests/client/toolkit_test_client_republish.c` Run it with: ```bash cd S2OPC/build-asan-event/bin ./toolkit_test_client_republish ``` Observed client-side output: ```bash client_initialize: status=0 connect: status=0 CreateSubscription: service=0x00000000 sub=20 revisedInterval=2000.00 create_subscription: status=0 CreateMonitoredItems: eventMi=2 dataMi=1 create_mixed_monitored_items: status=0 publish_drain: status=0 Publish[drain] service=0x00000000 sub=20 seq=1 notifData=1 more=0 notif[0] encoding=3 type=DataChangeNotification call_gen_event_method: status=0 publish_mixed: status=0 Publish[mixed:1] service=0x00000000 sub=20 seq=2 notifData=2 more=0 notif[0] encoding=3 type=DataChangeNotification notif[1] encoding=3 type=EventNotificationList Republish target: sub=20 seq=2 republish: status=8 toolkit_test_client_republish final result: NOK status=8 ``` This output is important because it demonstrates that the server first produced a **real mixed notification** with: - `notifData=2` - `notif[0] = DataChangeNotification` - `notif[1] = EventNotificationList` ### Server-side ASan crash The server then aborts during republish response serialization: <details> <summary>Click for the long ASan</summary> ```bash ================================================================= ==1083698==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x507000078138 at pc 0x6250bb58879f bp 0x712fc93fa210 sp 0x712fc93fa200 READ of size 4 at 0x507000078138 thread T5 #0 0x6250bb58879e in SOPC_ExtensionObject_Write /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:1830 #1 0x6250bb58ca8b in SOPC_Write_Array /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:3118 #2 0x6250bb57d59e in SOPC_EncodeableObject_Encode /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encodeabletype.c:1013 #3 0x6250bb57d71f in SOPC_EncodeableObject_Encode /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encodeabletype.c:1023 #4 0x6250bb58e410 in SOPC_EncodeMsg_Type_Header_Body /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:3158 #5 0x6250bb4ef13e in internal__message_out_bs__encode_msg /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/message_out_bs.c:282 #6 0x6250bb4efa31 in message_out_bs__encode_msg /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/message_out_bs.c:360 #7 0x6250bb4b29b1 in service_mgr__encode_session_service_resp /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:732 #8 0x6250bb4b51b2 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1190 #9 0x6250bb4ac72a in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #10 0x6250bb477466 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #11 0x6250bb552baa in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #12 0x712fcec94ac2 in start_thread nptl/pthread_create.c:442 #13 0x712fced268cf (/lib/x86_64-linux-gnu/libc.so.6+0x1268cf) 0x507000078138 is located 48 bytes to the right of 72-byte region [0x5070000780c0,0x507000078108) allocated by thread T5 here: #0 0x6250bb3bf6a7 in malloc (/home/weichuan/wc/S2OPC/build-asan-event/bin/toolkit_test_server+0x52c6a7) #1 0x6250bb504dc0 in msg_subscription_publish_ack_bs__setall_msg_republish_response /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/msg_subscription_publish_ack_bs.c:158 #2 0x6250bb4d972b in subscription_mgr__treat_subscription_republish_request /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_mgr.c:1257 #3 0x6250bb4b17a5 in service_mgr__treat_session_nano_extended_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:471 #4 0x6250bb4b2460 in service_mgr__treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:680 #5 0x6250bb4b2460 in service_mgr__decode_and_treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:630 #6 0x6250bb4b50b7 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1177 #7 0x6250bb4ac72a in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #8 0x6250bb477466 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #9 0x6250bb552baa in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #10 0x712fcec94ac2 in start_thread nptl/pthread_create.c:442 Thread T5 created by T0 here: #0 0x6250bb3634c5 in pthread_create (/home/weichuan/wc/S2OPC/build-asan-event/bin/toolkit_test_server+0x4d04c5) #1 0x6250bb54aaf1 in create_thread /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:275 #2 0x6250bb54aaf1 in SOPC_Thread_Create /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:336 #3 0x6250bb5533e2 in SOPC_Looper_Create /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:167 #4 0x6250bb47998b in SOPC_Services_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:904 #5 0x6250bb457233 in SOPC_Toolkit_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/configuration/sopc_toolkit_config.c:141 #6 0x6250bb428b83 in SOPC_CommonHelper_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/frontend/common_wrapper/libs2opc_common_config.c:145 #7 0x6250bb32b3f2 in Server_Initialize /home/weichuan/wc/S2OPC/tests/ClientServer/validation_tests/server/toolkit_test_server.c:290 #8 0x6250bb32b3f2 in main /home/weichuan/wc/S2OPC/tests/ClientServer/validation_tests/server/toolkit_test_server.c:1204 #9 0x712fcec29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:1830 in SOPC_ExtensionObject_Write Shadow bytes around the buggy address: 0x0a0e80006fd0: fa fa fd fd fd fd fd fd fd fd fd fa fa fa fa fa 0x0a0e80006fe0: fd fd fd fd fd fd fd fd fd fa fa fa fa fa 00 00 0x0a0e80006ff0: 00 00 00 00 00 00 00 fa fa fa fa fa fd fd fd fd 0x0a0e80007000: fd fd fd fd fd fa fa fa fa fa fd fd fd fd fd fd 0x0a0e80007010: fd fd fd fa fa fa fa fa 00 00 00 00 00 00 00 00 =>0x0a0e80007020: 00 fa fa fa fa fa fa[fa]fa fa fa fa fa fa fa fa 0x0a0e80007030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0e80007040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0e80007050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0e80007060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0e80007070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==1083698==ABORTING ``` </details> ### Result analysis The observed sequence is consistent with the source-level root cause: 1. the server legitimately builds a notification message containing **two** elements; 2. `RepublishResponse` reconstruction preserves `NoOfNotificationData == 2`; 3. the response allocates storage for only **one** `SOPC_ExtensionObject`; 4. the generic encoder serializes two elements and reads the second one out of bounds. --- ## Fix suggestion ### Fix strategy The `RepublishResponse` builder must preserve the invariant: > if `NotificationMessage.NoOfNotificationData == N`, then `NotificationMessage.NotificationData` must reference storage for **N** properly initialized `SOPC_ExtensionObject` elements. The safest repair is: 1. keep the shallow copy only for scalar fields; 2. reset `resp->NotificationMessage.NotificationData` before rebuilding it; 3. allocate an array sized to `NoOfNotificationData`; 4. initialize and deep-copy **each** source `SOPC_ExtensionObject`; 5. on partial failure, clear any copied elements and reset the response object to a safe state. ### Recommended code replacement Replace the current implementation of `msg_subscription_publish_ack_bs__setall_msg_republish_response()` in `src/ClientServer/services/b2c/msg_subscription_publish_ack_bs.c` with the following code: ```c void msg_subscription_publish_ack_bs__setall_msg_republish_response( const constants__t_msg_i msg_subscription_publish_ack_bs__p_resp_msg, const constants__t_notif_msg_i msg_subscription_publish_ack_bs__p_notifMsg, constants_statuscodes_bs__t_StatusCode_i* const msg_subscription_publish_ack_bs__sc) { *msg_subscription_publish_ack_bs__sc = constants_statuscodes_bs__e_sc_bad_out_of_memory; OpcUa_RepublishResponse* resp = (OpcUa_RepublishResponse*) msg_subscription_publish_ack_bs__p_resp_msg; const OpcUa_NotificationMessage* src = msg_subscription_publish_ack_bs__p_notifMsg; resp->NotificationMessage = *src; /* copy scalar fields first */ resp->NotificationMessage.NotificationData = NULL; if (src->NoOfNotificationData <= 0) { resp->NotificationMessage.NoOfNotificationData = 0; *msg_subscription_publish_ack_bs__sc = constants_statuscodes_bs__e_sc_ok; return; } if (NULL == src->NotificationData) { SOPC_Logger_TraceError( SOPC_LOG_MODULE_CLIENTSERVER, "msg_subscription_publish_ack_bs__setall_msg_republish_response: inconsistent source NotificationMessage"); resp->NotificationMessage.NoOfNotificationData = 0; return; } if ((uint64_t) src->NoOfNotificationData > SIZE_MAX / sizeof(SOPC_ExtensionObject)) { SOPC_Logger_TraceError( SOPC_LOG_MODULE_CLIENTSERVER, "msg_subscription_publish_ack_bs__setall_msg_republish_response: allocation overflow"); resp->NotificationMessage.NoOfNotificationData = 0; return; } resp->NotificationMessage.NotificationData = SOPC_Calloc( (size_t) src->NoOfNotificationData, sizeof(SOPC_ExtensionObject)); if (NULL == resp->NotificationMessage.NotificationData) { resp->NotificationMessage.NoOfNotificationData = 0; return; } for (int32_t i = 0; i < src->NoOfNotificationData; ++i) { SOPC_ExtensionObject_Initialize(&resp->NotificationMessage.NotificationData[i]); if (SOPC_ExtensionObject_Copy(&resp->NotificationMessage.NotificationData[i], &src->NotificationData[i]) != SOPC_STATUS_OK) { SOPC_Logger_TraceError( SOPC_LOG_MODULE_CLIENTSERVER, "msg_subscription_publish_ack_bs__setall_msg_republish_response: SOPC_ExtensionObject_Copy failure"); for (int32_t j = 0; j <= i; ++j) { SOPC_ExtensionObject_Clear(&resp->NotificationMessage.NotificationData[j]); } SOPC_Free(resp->NotificationMessage.NotificationData); resp->NotificationMessage.NotificationData = NULL; resp->NotificationMessage.NoOfNotificationData = 0; return; } } *msg_subscription_publish_ack_bs__sc = constants_statuscodes_bs__e_sc_ok; } ``` ---