wasm-micro-runtime icon indicating copy to clipboard operation
wasm-micro-runtime copied to clipboard

[wasm-c-api] uninitialized name##_idx_rt member when created by wasm_##name##_new

Open clover2123 opened this issue 2 years ago • 1 comments

Hi all!

I found the following bug(maybe?) in wasm-c-api implementation (lastest commit).

Each type structure (wasm_func_t, wasm_global_t, wasm_memory_t and wasm_table_t) has name##_idx_rt member like below, https://github.com/bytecodealliance/wasm-micro-runtime/blob/62fb3c9a89491d21aec00e123b421bd81aa7beaa/core/iwasm/common/wasm_c_api_internal.h#L181-L195 but this member is never initialized (just set to 0) when each type is created through wasm_##name##_new functions such as wasm_table_new.

It causes a problem when wasm_ref_t is generated and compared to other wasm_ref_t.

wasm_table_t* table1 = wasm_table_new(store, type1, nullptr)
wasm_ref_t* ref1 = wasm_table_as_ref(table1);
wasm_table_t* table2 = wasm_table_new(store, type2, nullptr)
wasm_ref_t* ref2 = wasm_table_as_ref(table2);

wasm_ref_same(ref1, ref2); // expect: false, but real: true

Since wasm_ref_same compares internal ref_idx_rt value which is set to name##_idx_rt of type structure, wasm_ref_same always returns a true value in the above case. IMHO name##_idx_rt should have unique id value when type structure is created, however current version does not support it.

Correct me if i'm wrong. Thanks.

clover2123 avatar Jul 29 '21 09:07 clover2123

First of first, when calling a wasm_XXX_new, it actually returns a host-side runtime object. It is isolated and separated from Wasm runtime object. They all need to be linked to a module instance by calling wasm_instance_new as an entry of imports.

Second of second, we actually don't support import/export a wasm_table_t. Because of the security concern. So, you will find out that we don't link a table to any Wasm runtime object and, as you say, "never initialized".

lum1n0us avatar Jul 30 '21 06:07 lum1n0us