## Summary A remote client can crash the official `toolkit_demo_server_alarms` server example in S2OPC 1.7.3 by sending a crafted `CreateMonitoredItemsRequest` that contains an `EventFilter` with two empty `WhereClause` elements. The bug is triggered in the server-side validation path for `CreateMonitoredItems(EventFilter)`.\ The implementation allocates a zero-length `OperandStatusCodes` array for each empty `ContentFilterElement`, leaves a **non-Good** operand status for the **second** `WhereClause` element because of an early return, and then **unconditionally writes** to `OperandStatusCodes[0]`. In an ASan build this results in a **heap-buffer-overflow / heap out-of-bounds write** and aborts the server process. This is a **server-side memory corruption bug** reachable through a **real OPC UA network request**.\ On the provided demo configuration, the issue is reproducible against the official `toolkit_demo_server_alarms` example. --- ## Version - **Version:** `1.7.3` - **Git tag:** `S2OPC_Toolkit_1.7.3` - **Commit:** `b4c5c7d63cd69698461d514b905a7c92b3c377c4` Observed build banner during reproduction: ```bash S2OPC_Common - Version: 1.7.3, SrcCommit: b4c5c7d63cd69698461d514b905a7c92b3c377c4 S2OPC_ClientServer - Version: 1.7.3, SrcCommit: b4c5c7d63cd69698461d514b905a7c92b3c377c4 ``` ## Full ASan <details> <summary>Click for Full ASan</summary> ```bash ================================================================= ==538569==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50200020a870 at pc 0x5aee3dd31117 bp 0x70c9f67f9ab0 sp 0x70c9f67f9aa0 WRITE of size 4 at 0x50200020a870 thread T5 #0 0x5aee3dd31116 in monitored_item_event_filter_where_clause_bs__set_where_element_result /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/monitored_item_event_filter_where_clause_bs.c:55 #1 0x5aee3dd7dfda in monitored_item_event_filter_where_clause__check_where_clause_and_fill_ctx_and_result /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/monitored_item_event_filter_where_clause.c:69 #2 0x5aee3dd7d109 in monitored_item_event_filter_treatment__check_monitored_item_event_filter_valid /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/monitored_item_event_filter_treatment.c:91 #3 0x5aee3dd7ea61 in monitored_item_filter_treatment__check_monitored_item_filter_valid_and_fill_result /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/monitored_item_filter_treatment.c:72 #4 0x5aee3dd91fb0 in subscription_core__create_monitored_item /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_core.c:1132 #5 0x5aee3dd06dfa in subscription_mgr__local_treat_create_monitored_item_index /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_mgr.c:264 #6 0x5aee3dd07173 in subscription_mgr__local_treat_create_monitored_items /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_mgr.c:315 #7 0x5aee3dd0d0bb in subscription_mgr__treat_subscription_create_monitored_items_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_mgr.c:1303 #8 0x5aee3dcdfc0f in service_mgr__treat_session_nano_extended_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:479 #9 0x5aee3dce0c27 in service_mgr__treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:680 #10 0x5aee3dce087b in service_mgr__decode_and_treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:630 #11 0x5aee3dce3601 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1177 #12 0x5aee3dcda7fc in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #13 0x5aee3dc86752 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #14 0x5aee3dda82e3 in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #15 0x70c9fb494ac2 in start_thread nptl/pthread_create.c:442 #16 0x70c9fb5268cf (/lib/x86_64-linux-gnu/libc.so.6+0x1268cf) 0x50200020a871 is located 0 bytes to the right of 1-byte region [0x50200020a870,0x50200020a871) allocated by thread T5 here: #0 0x5aee3dbcb6c7 in __interceptor_calloc (/home/weichuan/wc/S2OPC/build-alarms-gdb-asan/bin/toolkit_demo_server_alarms+0x12a6c7) #1 0x5aee3dd99277 in SOPC_Calloc /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_mem_alloc.c:37 #2 0x5aee3dd30b33 in monitored_item_event_filter_treatment_bs__init_event_filter_ctx_and_result /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/monitored_item_event_filter_treatment_bs.c:586 #3 0x5aee3dd7d03a in monitored_item_event_filter_treatment__check_monitored_item_event_filter_valid /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/monitored_item_event_filter_treatment.c:83 #4 0x5aee3dd7ea61 in monitored_item_filter_treatment__check_monitored_item_filter_valid_and_fill_result /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/monitored_item_filter_treatment.c:72 #5 0x5aee3dd91fb0 in subscription_core__create_monitored_item /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_core.c:1132 #6 0x5aee3dd06dfa in subscription_mgr__local_treat_create_monitored_item_index /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_mgr.c:264 #7 0x5aee3dd07173 in subscription_mgr__local_treat_create_monitored_items /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_mgr.c:315 #8 0x5aee3dd0d0bb in subscription_mgr__treat_subscription_create_monitored_items_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/subscription_mgr.c:1303 #9 0x5aee3dcdfc0f in service_mgr__treat_session_nano_extended_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:479 #10 0x5aee3dce0c27 in service_mgr__treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:680 #11 0x5aee3dce087b in service_mgr__decode_and_treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:630 #12 0x5aee3dce3601 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1177 #13 0x5aee3dcda7fc in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #14 0x5aee3dc86752 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #15 0x5aee3dda82e3 in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #16 0x70c9fb494ac2 in start_thread nptl/pthread_create.c:442 Thread T5 created by T0 here: #0 0x5aee3db6f315 in __interceptor_pthread_create (/home/weichuan/wc/S2OPC/build-alarms-gdb-asan/bin/toolkit_demo_server_alarms+0xce315) #1 0x5aee3dd9d778 in create_thread /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:275 #2 0x5aee3dd9db95 in SOPC_Thread_Create /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:336 #3 0x5aee3dda880c in SOPC_Looper_Create /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:167 #4 0x5aee3dc89517 in SOPC_Services_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:904 #5 0x5aee3dc5318e in SOPC_Toolkit_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/configuration/sopc_toolkit_config.c:141 #6 0x5aee3dc2035e in SOPC_CommonHelper_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/frontend/common_wrapper/libs2opc_common_config.c:145 #7 0x5aee3dc17562 in main /home/weichuan/wc/S2OPC/samples/ClientServer/demo_server_alarms/toolkit_demo_server_alarms.c:268 #8 0x70c9fb429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/monitored_item_event_filter_where_clause_bs.c:55 in monitored_item_event_filter_where_clause_bs__set_where_element_result Shadow bytes around the buggy address: 0x0a04800394b0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa 0x0a04800394c0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0a04800394d0: fa fa fd fd fa fa 00 01 fa fa 06 fa fa fa fd fd 0x0a04800394e0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0a04800394f0: fa fa fd fd fa fa 00 00 fa fa fd fa fa fa 00 fa =>0x0a0480039500: fa fa 00 fa fa fa 04 fa fa fa fd fa fa fa[01]fa 0x0a0480039510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0480039520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0480039530: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0480039540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a0480039550: 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 ==538569==ABORTING Aborted ``` </details> --- ## Security Impact - **Type:** heap-based buffer overflow / heap out-of-bounds write - **CWE:** **CWE-787** - **Affected role:** `server` - **Trigger surface:** `CreateMonitoredItems(EventFilter)` over a real OPC UA session - **Verified impact:** **remote server crash / denial of service** - **Potential impact:** the primitive is an actual heap write, so the bug is stronger than a simple logic error or parser rejection; however, I currently only claim **reliable DoS** because I do not have evidence for code execution. In the demo configuration used here, an **anonymous** remote client was able to trigger the fault.\ More generally, the bug affects any server deployment that exposes the same `CreateMonitoredItems(EventFilter)` path and reaches the vulnerable validation logic. --- ## Affected path ### User-controlled request path ```bash CreateMonitoredItemsRequest -> MonitoringParameters.Filter = EventFilter -> EventFilter.SelectClauses = 1 -> EventFilter.WhereClause.Elements = 2 -> both ContentFilterElement entries are left empty / default-initialized ``` ### Server-side call chain ```bash service_mgr__server_receive_session_service_req -> service_mgr__decode_and_treat_session_service_req -> service_mgr__treat_session_service_req -> service_mgr__treat_session_nano_extended_service_req -> subscription_mgr__treat_subscription_create_monitored_items_req -> subscription_mgr__local_treat_create_monitored_items -> subscription_mgr__local_treat_create_monitored_item_index -> subscription_core__create_monitored_item -> monitored_item_filter_treatment__check_monitored_item_filter_valid_and_fill_result -> monitored_item_event_filter_treatment__check_monitored_item_event_filter_valid -> monitored_item_event_filter_where_clause__check_where_clause_and_fill_ctx_and_result -> monitored_item_event_filter_where_clause_bs__set_where_element_result ``` ### Relevant files - `src/ClientServer/services/b2c/monitored_item_event_filter_where_clause_bs.c` - `src/ClientServer/services/b2c/monitored_item_event_filter_treatment_bs.c` - `src/ClientServer/services/bgenc/monitored_item_event_filter_where_clause.c` - `src/ClientServer/services/bgenc/monitored_item_event_filter_treatment.c` - `samples/ClientServer/demo_server_alarms/toolkit_demo_server_alarms.c` --- ## Root cause The vulnerability is caused by the interaction of **three separate implementation decisions**: 1. **Zero-length operand result arrays are allowed for empty `WhereClause` elements** 2. **The second and later `WhereClause` elements return early with a non-Good operand status** 3. **The result-writing function assumes `OperandStatusCodes[0]` always exists when `rawOperandSc` is non-Good** ### 1) Zero-length allocation of `OperandStatusCodes` During `EventFilterResult` initialization, the implementation allocates one `OperandStatusCodes` array per `WhereClause` element, using the request-controlled `NoOfFilterOperands` value directly: ```c eltResult->OperandStatusCodes = SOPC_Calloc((size_t) eventFilter->WhereClause.Elements[i].NoOfFilterOperands, sizeof(*eltResult->OperandStatusCodes)); if (NULL != eltResult->OperandStatusCodes) { eltResult->NoOfOperandStatusCodes = eventFilter->WhereClause.Elements[i].NoOfFilterOperands; } ``` When the client sends an empty `ContentFilterElement`, `NoOfFilterOperands == 0`.\ Therefore the server creates a logical result array of **length 0**. In my GDB session, both crafted `WhereClause` elements had: ```bash FilterOperator = 0 NoOfFilterOperands = 0 FilterOperands = NULL ``` and both `ElementResults[*].NoOfOperandStatusCodes` ended up as `0`. ### 2) The second `WhereClause` element returns early and preserves a non-Good operand status The element-checking function initializes both raw status values to `OpcUa_BadUnexpectedError`, then immediately returns for the second and later elements: ```c *statusCode = constants_statuscodes_bs__e_sc_bad_monitored_item_filter_unsupported; *operatorRawSc = OpcUa_BadUnexpectedError; *operandRawSc = OpcUa_BadUnexpectedError; if (eltArrayIdx > 0) { // Unsupported expression using operators return; } ``` This early return is the key reason why the PoC uses **two** empty `WhereClause` elements instead of one. - For the **first** element (`eltArrayIdx == 0`), the code continues and reaches later checks. Since `FilterOperator != OpcUa_FilterOperator_OfType`, the function sets: - `operatorRawSc = OpcUa_BadMonitoredItemFilterUnsupported` - `operandRawSc = SOPC_GoodGenericStatus` That means no operand error is recorded for the first empty element. - For the **second** element (`eltArrayIdx == 1`), the function returns immediately. As a result, `operandRawSc` stays **non-Good** (`OpcUa_BadUnexpectedError` in my debugging session). So the second empty element becomes the stable trigger that drives execution into the unsafe write path. ### 3) Unconditional write to `OperandStatusCodes[0]` The final write-side bug is in `monitored_item_event_filter_where_clause_bs__set_where_element_result`: ```c filterResult->WhereClauseResult.ElementResults[eltArrayIdx].StatusCode = rawOperatorSc; if (!SOPC_IsGoodStatus(rawOperandSc)) { filterResult->WhereClauseResult.ElementResults[eltArrayIdx] .OperandStatusCodes[0] = rawOperandSc; } else { SOPC_Free(filterResult->WhereClauseResult.ElementResults[eltArrayIdx].OperandStatusCodes); filterResult->WhereClauseResult.ElementResults[eltArrayIdx].OperandStatusCodes = NULL; filterResult->WhereClauseResult.ElementResults[eltArrayIdx].NoOfOperandStatusCodes = 0; } ``` There is **no check** for either: - `OperandStatusCodes != NULL` - `NoOfOperandStatusCodes > 0` So when the second crafted empty element reaches this function: - `NoOfOperandStatusCodes == 0` - `OperandStatusCodes` points to the result of `calloc(0, sizeof(...))` - `rawOperandSc` is non-Good The server then performs a **4-byte write** to `OperandStatusCodes[0]`, which is out of bounds for a zero-length result array. --- ## PoC Program [POC.zip](https://github.com/user-attachments/files/29177920/POC.zip) --- ## Reproduction ### Build commands From the repository root: ```bash env BUILD_DIR=build-asan \ S2OPC_CLIENTSERVER_ONLY=ON \ ENABLE_SAMPLES=ON \ ENABLE_TESTING=OFF \ WITH_ASAN=ON \ CMAKE_BUILD_TYPE=Debug \ CMAKE_C_FLAGS='-O0 -g3 -fno-omit-frame-pointer' \ WARNINGS_AS_ERRORS=OFF \ ./build.sh --jobs 8 --target toolkit_demo_server_alarms s2opc_wrapper_event_filter_async ``` If the build directory already exists: ```bash cmake --build build-asan -j 8 --target toolkit_demo_server_alarms s2opc_wrapper_event_filter_async ``` ### Start the server ```bash cd S2OPC/build-asan/bin env TEST_SERVER_XML_CONFIG=./S2OPC_Server_Demo_Config_unencrypted_none.xml \ TEST_SERVER_XML_ADDRESS_SPACE=./S2OPC_Demo_Alarms_NodeSet.xml \ TEST_USERS_XML_CONFIG=./S2OPC_Users_Demo_Config.xml \ ./toolkit_demo_server_alarms ``` ### Trigger the bug I used a **minimal wrapper-based client** to send a real `CreateMonitoredItemsRequest` with a crafted `EventFilter`.\ The request properties are: - `NoOfSelectClauses = 1` - `NoOfWhereClauseElements = 2` - both `ContentFilterElement` entries are left empty / default-initialized - therefore both elements have `NoOfFilterOperands = 0` Trigger command: ```bash cd S2OPC/build-asan/bin env EVENT_ASYNC_SERVER_URL='opc.tcp://127.0.0.1:4841' \ EVENT_ASYNC_SELECT_COUNT=1 \ EVENT_ASYNC_WHERE_COUNT=2 \ EVENT_ASYNC_WHERE_MODE=empty \ EVENT_ASYNC_WAIT_MS=10000 \ ./s2opc_wrapper_event_filter_async ``` ### Client-side output ```bash BuildAnonConfig status=0 cfg=0x5110000002c0 Connect status=0 connection=0x506000000080 CreateSubscription(sync) status=0 resp=0x510000008040 CreateSubscription(sync) service=0x00000000 subId=20 BuildCreateMIRequest status=0 req=0x5030000009d0 selectCount=1 whereCount=2 timeoutHint=60000 CreateMI(async) send status=0 AsyncServiceCb: send/request failure type=(nil) response=(nil) ClientConnectionEvent: event=0 status=0x80B50000 Async wait done=1 gotResp=0 elapsed=1200ms service=0x00000000 results=0 first=0x00000000 ``` ### Server-side ASan output ```bash ================================================================= ==538569==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50200020a870 WRITE of size 4 at 0x50200020a870 thread T5 #0 monitored_item_event_filter_where_clause_bs__set_where_element_result src/ClientServer/services/b2c/monitored_item_event_filter_where_clause_bs.c:55 #1 monitored_item_event_filter_where_clause__check_where_clause_and_fill_ctx_and_result src/ClientServer/services/bgenc/monitored_item_event_filter_where_clause.c:69 #2 monitored_item_event_filter_treatment__check_monitored_item_event_filter_valid src/ClientServer/services/bgenc/monitored_item_event_filter_treatment.c:91 #3 monitored_item_filter_treatment__check_monitored_item_filter_valid_and_fill_result src/ClientServer/services/bgenc/monitored_item_filter_treatment.c:72 #4 subscription_core__create_monitored_item src/ClientServer/services/bgenc/subscription_core.c:1132 ... 0x50200020a871 is located 0 bytes to the right of 1-byte region [0x50200020a870,0x50200020a871) allocated by thread T5 here: #0 __interceptor_calloc #1 SOPC_Calloc src/Common/helpers_platform_dep/linux/p_sopc_mem_alloc.c:37 #2 monitored_item_event_filter_treatment_bs__init_event_filter_ctx_and_result src/ClientServer/services/b2c/monitored_item_event_filter_treatment_bs.c:586 ``` --- ## Fix suggestion ### Recommended fix strategy A robust fix should address **all three contributing conditions**, not only the final write: 1. **Do not allocate operand result arrays when `NoOfFilterOperands <= 0`** 2. **Normalize the early-return path for unsupported additional `WhereClause` elements so that no operand status is reported when there are no operands** 3. **Guard the write to `OperandStatusCodes[0]` with both pointer and length checks** ### Why a single-line fix is not enough A one-line bounds check in `set_where_element_result()` would stop the immediate crash, but it would still leave inconsistent internal semantics: - a zero-length result array may still be represented by a non-NULL allocation, - the early-return path would still incorrectly preserve a non-Good operand status for an unsupported multi-element expression, - future code changes could reintroduce similar issues in other write sites. For that reason I recommend a **defense-in-depth patch**. --- ## Proposed patch ### Patch 1: do not allocate zero-length operand arrays **File:** `src/ClientServer/services/b2c/monitored_item_event_filter_treatment_bs.c` Replace the current inner initialization block with the following: ```c for (int32_t i = 0; SOPC_STATUS_OK == status && i < eventFilterResult->WhereClauseResult.NoOfElementResults; i++) { OpcUa_ContentFilterElementResult* eltResult = &eventFilterResult->WhereClauseResult.ElementResults[i]; OpcUa_ContentFilterElementResult_Initialize(eltResult); const int32_t nbOperands = eventFilter->WhereClause.Elements[i].NoOfFilterOperands; if (nbOperands > 0) { eltResult->OperandStatusCodes = SOPC_Calloc((size_t) nbOperands, sizeof(*eltResult->OperandStatusCodes)); if (NULL != eltResult->OperandStatusCodes) { eltResult->NoOfOperandStatusCodes = nbOperands; } else { status = SOPC_STATUS_OUT_OF_MEMORY; } } else { eltResult->OperandStatusCodes = NULL; eltResult->NoOfOperandStatusCodes = 0; } } ``` ### Patch 2: normalize the early-return path for additional `WhereClause` elements **File:** `src/ClientServer/services/b2c/monitored_item_event_filter_treatment_bs.c` Replace the beginning of `monitored_item_event_filter_treatment_bs__check_where_elt_and_fill_ctx` with: ```c SOPC_ASSERT(monitored_item_event_filter_treatment_bs__p_whereEltIdx > 0); const t_entier4 eltArrayIdx = monitored_item_event_filter_treatment_bs__p_whereEltIdx - 1; *monitored_item_event_filter_treatment_bs__statusCode = constants_statuscodes_bs__e_sc_bad_monitored_item_filter_unsupported; *monitored_item_event_filter_treatment_bs__operatorRawSc = OpcUa_BadUnexpectedError; *monitored_item_event_filter_treatment_bs__operandRawSc = OpcUa_BadUnexpectedError; if (eltArrayIdx > 0) { /* Unsupported multi-element where-clause expression. * This is an operator-level failure, not an operand-indexable failure. * Keep the operand status list empty. */ *monitored_item_event_filter_treatment_bs__operatorRawSc = OpcUa_BadMonitoredItemFilterUnsupported; *monitored_item_event_filter_treatment_bs__operandRawSc = SOPC_GoodGenericStatus; return; } ``` ### Patch 3: guard the final write **File:** `src/ClientServer/services/b2c/monitored_item_event_filter_where_clause_bs.c` Replace `monitored_item_event_filter_where_clause_bs__set_where_element_result` with: ```c void monitored_item_event_filter_where_clause_bs__set_where_element_result( const constants__t_filterResult_i monitored_item_event_filter_where_clause_bs__p_filterResult, const t_entier4 monitored_item_event_filter_where_clause_bs__p_whereEltIdx, const constants__t_RawStatusCode monitored_item_event_filter_where_clause_bs__p_rawOperatorSc, const constants__t_RawStatusCode monitored_item_event_filter_where_clause_bs__p_rawOperandSc) { SOPC_ASSERT(monitored_item_event_filter_where_clause_bs__p_whereEltIdx > 0); const t_entier4 eltArrayIdx = monitored_item_event_filter_where_clause_bs__p_whereEltIdx - 1; OpcUa_ContentFilterElementResult* eltResult = &monitored_item_event_filter_where_clause_bs__p_filterResult ->WhereClauseResult.ElementResults[eltArrayIdx]; eltResult->StatusCode = monitored_item_event_filter_where_clause_bs__p_rawOperatorSc; if (!SOPC_IsGoodStatus(monitored_item_event_filter_where_clause_bs__p_rawOperandSc)) { if (eltResult->NoOfOperandStatusCodes > 0 && NULL != eltResult->OperandStatusCodes) { eltResult->OperandStatusCodes[0] = monitored_item_event_filter_where_clause_bs__p_rawOperandSc; } else { /* No operand slots exist for this element. Keep the list empty. */ SOPC_Free(eltResult->OperandStatusCodes); eltResult->OperandStatusCodes = NULL; eltResult->NoOfOperandStatusCodes = 0; } } else { /* OPC UA Part 4 Table 119: * operandStatusCodes list is empty if no operand error occurred. */ SOPC_Free(eltResult->OperandStatusCodes); eltResult->OperandStatusCodes = NULL; eltResult->NoOfOperandStatusCodes = 0; } } ```