## Summary A server built from upstream S2OPC 1.7.3 can be crashed remotely through the AddNodes service when Node Management is enabled. The issue is a **server-side type confusion** in the `AddNodes` path: - the request declares **`NodeClass = Variable`** - but the `NodeAttributes` ExtensionObject is actually **`OpcUa_NodeAttributes`** (generic attributes), not **`OpcUa_VariableAttributes`** - the server **accepts** that generic type during validation - the server then **downcasts** the object to `const OpcUa_VariableAttributes*` - later code reads **VariableAttributes-specific members** from the smaller heap object This results in a **heap out-of-bounds read** and, under ASan, a reliable **`heap-buffer-overflow`** in the server process. A remote client that is allowed to use **AddNodes** can crash the server (**DoS**). --- ## Version - **Version:** `1.7.3` - **Commit:** `b4c5c7d63cd69698461d514b905a7c92b3c377c4` --- ## Impact ### Security impact **Remote denial of service in the server** through a malformed but successfully decoded `AddNodesRequest`. The issue is not a parser-only problem and does not require directly calling internal APIs. It is triggered through the **real server-side Node Management service path**. ### Expected security classification - **Bug class:** server-side type confusion leading to heap out-of-bounds read - **Observed effect:** server crash / remote DoS - **ASan manifestation:** `heap-buffer-overflow` (`READ of size 1`) --- ## Affected path ### Service path `AddNodesRequest` → `service_add_nodes_1__treat_add_nodes_item` → `address_space__addNode_AddressSpace` → `address_space_bs__addNode_AddressSpace_Variable` → `SOPC_AddressSpaceAccess_AddVariableNode` → `AddSingleVariableNode` → `SOPC_NodeMgtHelperInternal_AddVariableNodeAttributes` ### Relevant source locations - `src/ClientServer/services/b2c/address_space_bs.c` - `address_space_bs__addNode_check_valid_node_attributes_type` - `address_space_bs__addNode_AddressSpace_Variable` - `src/ClientServer/address_space/internal/sopc_node_mgt_helper_internal.c` - `SOPC_NodeMgtHelperInternal_AddVariableNodeAttributes` --- ## Root cause ### 1. Overly permissive type validation The first issue is in: `src/ClientServer/services/b2c/address_space_bs.c` `address_space_bs__addNode_check_valid_node_attributes_type(...)` For `NodeClass = Variable`, the function sets the expected type to: ```c expectedNodeAttrsType = &OpcUa_VariableAttributes_EncodeableType; ``` But the actual acceptance logic is: ```c // EncodeableType might be either the generic attributs type (common to all nodes) or specialized for node class if (&OpcUa_NodeAttributes_EncodeableType == actualNodeAttrsType || expectedNodeAttrsType == actualNodeAttrsType) { *address_space_bs__bres = true; } else { *address_space_bs__bres = false; } ``` So in a **Variable** context, the code explicitly treats both of these as valid: - `OpcUa_VariableAttributes` - **`OpcUa_NodeAttributes`** That is the first half of the bug: **generic attributes are allowed to enter a specialized Variable-node path**. At the validation breakpoint, the runtime values were: - `nodeClass = constants__e_ncl_Variable` - `actualType = "NodeAttributes"` - `actualValuePtr = 0x50b000025b30` This confirms that the request was decoded into a real **generic `NodeAttributes` object**, yet it still passed the validation function. ### 2. Unsafe downcast in the Variable add-node path The second issue is in: `src/ClientServer/services/b2c/address_space_bs.c` `address_space_bs__addNode_AddressSpace_Variable(...)` The function explicitly accepts both the generic and specialized types: ```c SOPC_ASSERT(&OpcUa_NodeAttributes_EncodeableType == address_space_bs__p_nodeAttributes->Body.Object.ObjType || &OpcUa_VariableAttributes_EncodeableType == address_space_bs__p_nodeAttributes->Body.Object.ObjType); ``` It then unconditionally performs the downcast: ```c (const OpcUa_VariableAttributes*) address_space_bs__p_nodeAttributes->Body.Object.Value ``` and passes that pointer to: ```c SOPC_AddressSpaceAccess_AddVariableNode(...) ``` This is the actual type-confusion sink. At this point the runtime values were: - `ObjType = "NodeAttributes"` - `Body.Object.Value = 0x50b000025b30` So the pointer still refers to the smaller **generic** object, but is now being treated as `OpcUa_VariableAttributes*`. ### 3. Why the common prefix appears to work The downstream helper is: `src/ClientServer/address_space/internal/sopc_node_mgt_helper_internal.c` `SOPC_NodeMgtHelperInternal_AddVariableNodeAttributes(...)` Its signature already assumes that the caller is passing a valid specialized object: ```c SOPC_ReturnStatus SOPC_NodeMgtHelperInternal_AddVariableNodeAttributes( SOPC_AddressSpace* addSpace, SOPC_AddressSpace_Node* node, OpcUa_VariableNode* varNode, const OpcUa_VariableAttributes* varAttributes, SOPC_StatusCode* scAddNode) ``` At the top of the function, the source itself documents why the bug does not immediately fail: ```c // Common fields have same offsets in OpcUa_Node and OpcUa_VariableNode // Common attributes have same offsets in OpcUa_NodeAttributes and OpcUa_VariableAttributes status = util_AddCommonNodeAttributes((OpcUa_Node*) varNode, (const OpcUa_NodeAttributes*) varAttributes, scAddNode); ``` This means the code intentionally relies on **shared prefix layout compatibility** between: - `OpcUa_NodeAttributes` - `OpcUa_VariableAttributes` As a result, the call to `util_AddCommonNodeAttributes(...)` can succeed even when the dynamic object is actually the smaller generic structure. At the helper entry breakpoint: - `varAttributes = 0x50b000025b30` - `varAttributes->encodeableType->TypeName = "NodeAttributes"` - `varAttributes->SpecifiedAttributes = 0x0` This is the key observation: - the **static type** is `const OpcUa_VariableAttributes*` - the **dynamic object type** is still `"NodeAttributes"` No larger object was created. The same smaller heap allocation was simply reinterpreted as a larger structure. ### 4. The first real out-of-bounds read After the common prefix is processed, the helper starts reading **VariableAttributes-specific fields**. The crucial sequence is: ```c if (0 != (varAttributes->SpecifiedAttributes & OpcUa_NodeAttributesMask_AccessLevel)) { varNode->AccessLevel = varAttributes->AccessLevel; } else { // Allow read access varNode->AccessLevel = 1; // bit 0 set } if (0 != (varAttributes->SpecifiedAttributes & OpcUa_NodeAttributesMask_UserAccessLevel) || (varAttributes->UserAccessLevel != 0 && varAttributes->UserAccessLevel != varAttributes->AccessLevel)) { ... } ``` In the reproducer, `SpecifiedAttributes` is deliberately set to `0`. That has an important control-flow effect: - the `AccessLevel` branch is **not** taken, so no read of `varAttributes->AccessLevel` occurs there - the left side of the `UserAccessLevel` condition is also false - because of C short-circuit evaluation, execution continues into the right side - the **first actual read of a VariableAttributes-only field** is therefore `varAttributes->UserAccessLevel` That is where the invalid access occurs. #### GDB / ASan field geometry Observed locally: - `sizeof(OpcUa_NodeAttributes) = 104` - `sizeof(OpcUa_VariableAttributes) = 208` - `offsetof(AccessLevel) = 0xb8` - `offsetof(UserAccessLevel) = 0xb9` Observed addresses: - allocation range: `[0x50b000025b30, 0x50b000025b98)` (size `104`) - `&varAttributes->AccessLevel = 0x50b000025be8` - `&varAttributes->UserAccessLevel = 0x50b000025be9` - ASan invalid read address: `0x50b000025be9` Distance past the real object end: - `0x50b000025be9 - 0x50b000025b98 = 0x51 = 81` So the crash is fully explained by the structure mismatch: - the real heap object is only **104 bytes** - the code assumes it may safely access fields at offsets such as **`0xb9`** - the first read of `UserAccessLevel` lands **81 bytes past the end** of the real allocation --- ## PoC [PoC.zip](https://github.com/user-attachments/files/29702766/PoC.zip) --- ## Reproduction ### Build The issue was reproduced on the upstream validation server with AddressSanitizer enabled and Node Management explicitly enabled. For the client reproducer, I used a minimal local validation client target that sends a malformed `AddNodesRequest` with: - `NodeClass = Variable` - `TypeDefinition = BaseDataVariableType` - `NodeAttributes.ObjType = &OpcUa_NodeAttributes_EncodeableType` - `SpecifiedAttributes = 0` > Note: `toolkit_test_client_add_nodes_generic_attrs` is a small local reproducer client used to trigger the upstream server bug. The vulnerable server target itself is upstream. ```bash cd S2OPC cmake -S . -B build-asan-node \ -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_NODE_MANAGEMENT=ON ``` The upstream tree already defines the official validation server target: ```bash cmake --build build-asan-node -j 8 --target toolkit_test_server toolkit_test_client_add_nodes_generic_attrs ``` ### Run #### 1. Start the official server ```bash cd build-asan-node/bin env TEST_PASSWORD_PRIVATE_KEY=password ./toolkit_test_server ``` Expected startup: ```bash <Test_Server_Toolkit: @ space configured <Demo_Server: Server started ``` #### 2. Send the malformed AddNodes request ```bash cd build-asan-node/bin env TEST_CLIENT_XML_CONFIG=./S2OPC_Client_Test_Config.xml \ TEST_PASSWORD_PRIVATE_KEY=password \ ./toolkit_test_client_add_nodes_generic_attrs ``` Client-side output: ```bash sending malformed AddNodes request: Variable node with generic OpcUa_NodeAttributes ServiceSync status=8 response=(nil) toolkit_test_client_add_nodes_generic_attrs final result: NOK status=8 ``` ### ASan result Server-side crash: <details> <summary>Click for Full ASan</summary> ```bash Session event SESSION_CREATION for session name=S2OPC_Session_20 id=20 with status=0x0 and client opc.tcp://localhost:484 using application S2OPC_TestClient with user ??? Session event SESSION_ACTIVATION for session name=S2OPC_Session_20 id=20 with status=0x0 and client opc.tcp://localhost:484 using application S2OPC_TestClient with user (null) ================================================================= ==1193343==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50b000025be9 at pc 0x5a1834569b39 bp 0x72d4881f9c90 sp 0x72d4881f9c80 READ of size 1 at 0x50b000025be9 thread T5 #0 0x5a1834569b38 in SOPC_NodeMgtHelperInternal_AddVariableNodeAttributes /home/weichuan/wc/S2OPC/src/ClientServer/address_space/internal/sopc_node_mgt_helper_internal.c:568 #1 0x5a183452b837 in AddSingleVariableNode /home/weichuan/wc/S2OPC/src/ClientServer/address_space/sopc_address_space_access.c:1221 #2 0x5a1834531336 in SOPC_AddressSpaceAccess_AddVariableNode /home/weichuan/wc/S2OPC/src/ClientServer/address_space/sopc_address_space_access.c:1265 #3 0x5a18345829e5 in address_space_bs__addNode_AddressSpace_Variable /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/address_space_bs.c:284 #4 0x5a18346368a4 in address_space__addNode_AddressSpace /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/address_space.c:766 #5 0x5a183464c966 in service_add_nodes_1__treat_add_nodes_item /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_add_nodes_1.c:271 #6 0x5a183464a880 in service_add_nodes__local_treat_add_nodes_index /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_add_nodes.c:99 #7 0x5a183464b00d in service_add_nodes__local_treat_add_nodes_items /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_add_nodes.c:131 #8 0x5a183464b00d in service_add_nodes__treat_add_nodes_request /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_add_nodes.c:162 #9 0x5a18345c7505 in service_mgr__treat_session_nano_extended_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:531 #10 0x5a18345c8060 in service_mgr__treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:680 #11 0x5a18345c8060 in service_mgr__decode_and_treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:630 #12 0x5a18345cacb7 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1177 #13 0x5a18345c232a in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #14 0x5a183458d066 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #15 0x5a18346687aa in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #16 0x72d48d894ac2 in start_thread nptl/pthread_create.c:442 #17 0x72d48d9268cf (/lib/x86_64-linux-gnu/libc.so.6+0x1268cf) 0x50b000025be9 is located 81 bytes to the right of 104-byte region [0x50b000025b30,0x50b000025b98) allocated by thread T5 here: #0 0x5a18344d6507 in __interceptor_malloc (/home/weichuan/wc/S2OPC/build-asan-node/bin/toolkit_test_server+0x52b507) #1 0x5a183469ea6d in SOPC_ExtensionObject_Read /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:1974 #2 0x5a18346902da in SOPC_EncodeableObject_Decode /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encodeabletype.c:1274 #3 0x5a183469efd1 in SOPC_Read_Array /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:3064 #4 0x5a18346904a5 in SOPC_EncodeableObject_Decode /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encodeabletype.c:1263 #5 0x5a18346a44ce in SOPC_DecodeMsg_HeaderOrBody /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:3202 #6 0x5a1834603fe8 in message_in_bs__decode_msg /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/message_in_bs.c:198 #7 0x5a18345c7b13 in service_mgr__decode_and_treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:607 #8 0x5a18345cacb7 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1177 #9 0x5a18345c232a in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #10 0x5a183458d066 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #11 0x5a18346687aa in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #12 0x72d48d894ac2 in start_thread nptl/pthread_create.c:442 Thread T5 created by T0 here: #0 0x5a183447a325 in __interceptor_pthread_create (/home/weichuan/wc/S2OPC/build-asan-node/bin/toolkit_test_server+0x4cf325) #1 0x5a18346606f1 in create_thread /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:275 #2 0x5a18346606f1 in SOPC_Thread_Create /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:336 #3 0x5a1834668fe2 in SOPC_Looper_Create /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:167 #4 0x5a183458f58b in SOPC_Services_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:904 #5 0x5a183456cfa3 in SOPC_Toolkit_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/configuration/sopc_toolkit_config.c:141 #6 0x5a183453e833 in SOPC_CommonHelper_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/frontend/common_wrapper/libs2opc_common_config.c:145 #7 0x5a1834442396 in Server_Initialize /home/weichuan/wc/S2OPC/tests/ClientServer/validation_tests/server/toolkit_test_server.c:290 #8 0x5a1834442396 in main /home/weichuan/wc/S2OPC/tests/ClientServer/validation_tests/server/toolkit_test_server.c:1204 #9 0x72d48d829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/weichuan/wc/S2OPC/src/ClientServer/address_space/internal/sopc_node_mgt_helper_internal.c:568 in SOPC_NodeMgtHelperInternal_AddVariableNodeAttributes Shadow bytes around the buggy address: 0x0a167fffcb20: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0a167fffcb30: fd fd fa fa fa fa fa fa fa fa fd fd fd fd fd fd 0x0a167fffcb40: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x0a167fffcb50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa 0x0a167fffcb60: fa fa fa fa fa fa 00 00 00 00 00 00 00 00 00 00 =>0x0a167fffcb70: 00 00 00 fa fa fa fa fa fa fa fa fa fa[fa]fa fa 0x0a167fffcb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a167fffcb90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a167fffcba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a167fffcbb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a167fffcbc0: 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 ==1193343==ABORTING ``` </details> This matches the source-level reasoning exactly: - the request survives decoding - the generic object passes validation - the generic object is downcast to `OpcUa_VariableAttributes*` - the helper reads `UserAccessLevel` - the server crashes on a heap out-of-bounds read --- ## Fix suggestion ### Recommended fix strategy The safest and simplest fix is to **stop accepting generic `OpcUa_NodeAttributes` for concrete AddNodes paths that later dereference specialized fields**. In other words: - for `NodeClass = Variable`, require **exactly** `OpcUa_VariableAttributes` - fail closed with `BadNodeAttributesInvalid` when the type does not match - add a second guard at the cast site so that a future validation regression cannot silently reintroduce the issue ### Suggested patch #### 1. Tighten validation in `address_space_bs__addNode_check_valid_node_attributes_type` Replace the permissive acceptance logic with an exact-type match. ```diff diff --git a/src/ClientServer/services/b2c/address_space_bs.c b/src/ClientServer/services/b2c/address_space_bs.c index XXXXXXX..YYYYYYY 100644 --- a/src/ClientServer/services/b2c/address_space_bs.c +++ b/src/ClientServer/services/b2c/address_space_bs.c @@ -2861,97 +2861,91 @@ void address_space_bs__addNode_check_valid_node_attributes_type( const constants__t_NodeAttributes_i address_space_bs__p_nodeAttributes, t_bool* const address_space_bs__bres) { // Check NodeAttributes is well decoded as an OPC UA object: verified in msg_node_management_add_nodes_bs SOPC_ASSERT(SOPC_ExtObjBodyEncoding_Object == address_space_bs__p_nodeAttributes->Encoding); // Check NodeAttributes type depending on NodeClass SOPC_EncodeableType* expectedNodeAttrsType = NULL; switch (address_space_bs__p_nodeClass) { case constants__e_ncl_Object: expectedNodeAttrsType = &OpcUa_ObjectAttributes_EncodeableType; break; case constants__e_ncl_Variable: expectedNodeAttrsType = &OpcUa_VariableAttributes_EncodeableType; break; case constants__e_ncl_Method: expectedNodeAttrsType = &OpcUa_MethodAttributes_EncodeableType; break; case constants__e_ncl_ObjectType: expectedNodeAttrsType = &OpcUa_ObjectTypeAttributes_EncodeableType; break; case constants__e_ncl_VariableType: expectedNodeAttrsType = &OpcUa_VariableTypeAttributes_EncodeableType; break; case constants__e_ncl_ReferenceType: expectedNodeAttrsType = &OpcUa_ReferenceTypeAttributes_EncodeableType; break; case constants__e_ncl_DataType: expectedNodeAttrsType = &OpcUa_DataTypeAttributes_EncodeableType; break; case constants__e_ncl_View: expectedNodeAttrsType = &OpcUa_ViewAttributes_EncodeableType; break; default: SOPC_ASSERT(false && "NodeClass must have been already checked by " "msg_node_management_add_nodes_bs__getall_add_node_item_req_params"); } SOPC_EncodeableType* actualNodeAttrsType = address_space_bs__p_nodeAttributes->Body.Object.ObjType; - // EncodeableType might be either the generic attributs type (common to all nodes) or specialized for node class - if (&OpcUa_NodeAttributes_EncodeableType == actualNodeAttrsType || expectedNodeAttrsType == actualNodeAttrsType) - { - *address_space_bs__bres = true; - } - else - { - *address_space_bs__bres = false; - } + // Concrete AddNodes paths later dereference node-class-specific members. + // Therefore the ExtensionObject type must exactly match the expected specialized type. + *address_space_bs__bres = (expectedNodeAttrsType == actualNodeAttrsType); } ``` #### 2. Add a fail-closed guard before the Variable downcast Even after tightening the validation helper, the cast site should defend itself. ```diff diff --git a/src/ClientServer/services/b2c/address_space_bs.c b/src/ClientServer/services/b2c/address_space_bs.c index XXXXXXX..YYYYYYY 100644 --- a/src/ClientServer/services/b2c/address_space_bs.c +++ b/src/ClientServer/services/b2c/address_space_bs.c @@ -2695,6 +2695,20 @@ void address_space_bs__addNode_AddressSpace_Variable( SOPC_UNUSED_ARG(address_space_bs__p_nodeClass); // For B precondition SOPC_ASSERT(NULL != address_space_bs__p_nodeAttributes); SOPC_ASSERT(SOPC_ExtObjBodyEncoding_Object == address_space_bs__p_nodeAttributes->Encoding); - SOPC_ASSERT(&OpcUa_NodeAttributes_EncodeableType == address_space_bs__p_nodeAttributes->Body.Object.ObjType || - &OpcUa_VariableAttributes_EncodeableType == address_space_bs__p_nodeAttributes->Body.Object.ObjType); + + if (&OpcUa_VariableAttributes_EncodeableType != address_space_bs__p_nodeAttributes->Body.Object.ObjType || + NULL == address_space_bs__p_nodeAttributes->Body.Object.Value) + { + util_status_code__C_to_B(OpcUa_BadNodeAttributesInvalid, address_space_bs__sc_addnode); + return; + } SOPC_AddressSpaceAccess* addSpaceAccess = SOPC_AddressSpaceAccess_Create(address_space_bs__nodes, true); bool recursive = S2OPC_NODE_INTERNAL_ADD_CHILD_NODES || !address_space_bs__p_local; SOPC_StatusCode retCode = SOPC_AddressSpaceAccess_AddVariableNode( addSpaceAccess, address_space_bs__p_parentNid, address_space_bs__p_refTypeId, address_space_bs__p_newNodeId, address_space_bs__p_browseName, (const OpcUa_VariableAttributes*) address_space_bs__p_nodeAttributes->Body.Object.Value, address_space_bs__p_typeDefId, recursive); ``` ---