You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the development of #111645 I found various type confusion issues in our existing Mono source code. Backporting the fixes for these issues is not necessarily worth it since the resulting behavior change could expose new bugs or change application behavior, but it's worth tracking all of the latent issues here in case we need to fix them later to address customer-facing issues.
There are probably more errors of this type that I didn't find.
utf16_array can be NULL and that scenario is not handled. The current implementation could potentially erroneously mess with the heap in the zero page on WASM; on other targets it should fail-fast.
The fallthrough from GENERICINST to VALUETYPE results in various accesses to klass being incorrect. Note that there are many functions with the same error.
This copy-paste error treats as CLASS as a GENERICINST and as a result the comparison against Task will probably never succeed and could crash instead.
This call to mono_class_from_mono_type_internal is being passed &blob_type which does not match the pattern from icall.c or from its neighboring calls, so it's possibly (but not certainly) an error.
* Guard members of MonoType union behind type check helpers
* Add _unchecked to call sites that are obviously guarded correctly
* Fix type confusion in bulk_type_log_single_type
* Fix genericinst fallthrough treating a MonoGenericClass ptr as a MonoClass ptr
* Fix type confusion in amd64 mini
* Fix type confusion in aot-runtime-wasm
* Prune a dead goto to make unchecked safe
* Fix two cases where we were partially initializing a stack-allocated MonoType instead of fully initializing it
* See #112395 for detailed list of bugs fixed
During the development of #111645 I found various type confusion issues in our existing Mono source code. Backporting the fixes for these issues is not necessarily worth it since the resulting behavior change could expose new bugs or change application behavior, but it's worth tracking all of the latent issues here in case we need to fix them later to address customer-facing issues.
There are probably more errors of this type that I didn't find.
runtime/src/mono/mono/metadata/metadata.c
Line 7028 in 109c946
type
is eitherARRAY
orSZARRAY
; the two types have different internal representations so the access toklass
here is incorrect.runtime/src/mono/mono/metadata/marshal.c
Line 6447 in 109c946
utf16_array
can be NULL and that scenario is not handled. The current implementation could potentially erroneously mess with the heap in the zero page on WASM; on other targets it should fail-fast.runtime/src/mono/mono/mini/mini.c
Line 1068 in 109c946
runtime/src/mono/mono/mini/mini.c
Line 1379 in 109c946
runtime/src/mono/mono/mini/mini-amd64.c
Line 312 in 109c946
The fallthrough from
GENERICINST
toVALUETYPE
results in various accesses toklass
being incorrect. Note that there are many functions with the same error.runtime/src/mono/mono/mini/aot-runtime-wasm.c
Line 75 in 109c946
The use of
klass
on aGENERICINST
is incorrect.runtime/src/mono/mono/mini/mini-generic-sharing.c
Line 3621 in 109c946
This copy-paste error treats as
CLASS
as aGENERICINST
and as a result the comparison againstTask
will probably never succeed and could crash instead.runtime/src/mono/mono/metadata/icall.c
Line 6596 in 109c946
runtime/src/mono/mono/metadata/reflection.c
Line 1033 in 109c946
These stack-allocated
MonoType
s are not fully initialized which means the additional data in the type is random garbage from the stack.runtime/src/mono/mono/metadata/reflection.c
Line 1045 in 109c946
This call to
mono_class_from_mono_type_internal
is being passed&blob_type
which does not match the pattern from icall.c or from its neighboring calls, so it's possibly (but not certainly) an error.runtime/src/mono/mono/eventpipe/ep-rt-mono-runtime-provider.c
Line 1557 in 109c946
Fallthrough for
ARRAY
andSZARRAY
is incorrect since they have different internal representations.The text was updated successfully, but these errors were encountered: