As #6359 pointed out, calling const_missing hook from E_XXX_ERROR (that
calls mrb_exc_get_id()) can be an attack vector. Since E_XXX_ERROR is
supposed to be a defined error class, we think that the situation where
it is undefined and the const_missing hook is called should be detected
as an error; fix#6359
The callinfo refers blk since #5786 but not marked at the time. Later we
added reclamation check by #5791 but its repeated heap scans decrease
the performance drastically in some cases. So the original @dearblue's
solution should be taken
Probably we need to always keep the original block at the bottom of
arguments. And the explicit block argument should be a normal local
variable. We will investigate it later.
The new version gives more accurate values for decimal number
representation that are not divisible in binary representations, for
example `0.3`.
The function uses `long double` for precision. Please report if `long
double` causes problems on any platform (especially microcontrollers).
Ref #6182
The `mrb_get_argv()` function and the `*` specifier of `mrb_get_args()` get the address of the argument.
At this time, if it is passed in the form of a splat argument, it will be an address to an element of an array object.
After getting the pointer to the array object, the caller may call `mrb_vm_exec()` directly or indirectly.
At this time, a splat argument with the class set can be retrieved as an array object by searching with `ObjectSpace.each_object`.
If changes are made as array objects, addresses on the heap as arrays may become invalid, or objects in the array may be recycled by the GC.
When the caller references the changed address in a subsequent operation, use-after-free is established.
This patch assigns `NULL` as the class of the array object so that it cannot be detected by `ObjectSpace.each_object` from the Ruby side.
`mrb_equal()` may call `obj.==` method internally.
Therefore, using an unupdated pointer and length after `mrb_equal()` could result in a read/write to an invalid address.
Fresh properties must always be obtained regardless of the result of `mrb_equal()`.
Also, `ary_modify()` must be called each time before writing.
ref. #6339
The C local variable is not protected from GC, so we use the function
mrb_gc_protect() to keep the value. We also keep the arena position by
mrb_gc_arena_save(), then restoring the position for every new return
value, to minimize arena size.
Small cosmetic changes (pre-increment to post-increment) are also made
in this commit.
When calling `mrb_equal()` or `mrb_funcall()` family functions, the GC arena should be restored if the loop is repeated by a non-immediate return value.
In my opinion, restoring the GC arena is unnecessary when a non-immediate (true) value causes the function to return (e.g. the `mrb_ary_index_m()` function).
The patch does not take into account the case of recursive calls and may be incomplete.
The `mrb_ary_cmp()` function calls `mrb_cmp()` for comparison, but `mrb_cmp()` may call the `obj.<=>` method internally.
If a user-defined `<=>` method is called and the array object under comparison is expanded or reduced, a reference to an invalid address may subsequently be made.
We assumed there's no need for gc_arena_keep() when MRB_GC_FIXED_ARENA
is set. But it turned out that gc_protect() still can cause use-after-free
with fixed arena.
Revert "gc.c (gc_protect): should not call gc_arena_keep twice from allocation"
This reverts commit 28ece4ed8b.
Revert "gc.c (gc_arena_keep): reorganized for MRB_GC_FIXED_ARENA; ref #6329"
This reverts commit 33dd623a02.
Static proc objects defined as methods may be placed in 4-byte alignments in 32-bit environments.
This may be misinterpreted as an immediate value depending on the address.
Since C11 and C++11 have additional language features for byte alignment, corresponding compilers use them to define the `mrb_alignas()` macro.
For earlier compilers, they use their own extensions to define the `mrb_alignas()` macro.
GCC supports `__attribute__((aligned(alignment)))` since at least version 2.95.3 (1999).
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#IDX305
According to GPT-4, support was added in version 2.7 (1995).
It is not known which version of Visual C++ added support for `__declspec(align(n))`.
According to GPT-4, at least Visual C++ 6.0 (1998) seems to support it.
Also, the documentation of past Intel C/C++ compilers that support `__declspec(align(n))` makes reference to support with Visual C++ 4.2 (1996).
https://www.intel.com/content/dam/www/public/ijkk/jp/ja/documents/developer/ccomp40j.pdf
When GC occurs during the expansion of the GC arena by `gc_protect()` in `mrb_obj_alloc()`, the object page just allocated by `add_heap()` is released.
Therefore, as soon as control returns from `gc_protect()`, there is a possibility of illegal writing or reading to the address just released.
This issue was discovered during the investigation of #6326.
The following assertions can be added to omit the `if` block
- env object must be non-null
- env object must be in a shared state with the stack
The current caller is believed to satisfy the condition.
A reference to an invalid address might occur in `is_dead()` of `obj_free()` called from `incremental_sweep_phase()`.
This would happen if the heap page was freed ahead of time in the same `incremental_sweep_phase()`.
fixed#6326
If comparing function (block or `<=>`) modifies the sorting array and GC
happens after the modification, objects passed to comparison may be
freed by GC.
Yukihiro "Matz" Matsumoto