Fix possible use after free in mrb_class_find_path
#5754
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
mrb_class_find_path
resolves achar*
pointer to a class name stringby calling
mrb_class_name
. It then allocates a new string withcapacity 40 to copy that
char*
into.mruby/src/variable.c
Lines 1111 to 1112 in e041841
mrb_class_name
resolves the class name viaclass_name_str
, whichreturns an
mrb_value
with type tagMRB_TT_STRING
and backed by anRString*
. Thenmrb_class_name
extracts theRSTRING_PTR
:mruby/src/class.c
Lines 2133 to 2134 in e041841
That
RString*
-backedmrb_value
ultimately comes frommrb_class_path
which resolves the string from the symbol table:
mruby/src/class.c
Line 2111 in e041841
The allocation of the target
str
after resolving the class namemrb_value
and extracting its pointer is fragile and assumes theRString*
is "static". If theRString*
is not static, theinterleaving of extracting the
RSTRING_PTR
followed by a subsequentallocation might result in the class name
mrb_value
being garbagecollected, which will leave the extracted pointer invalid.
Fix this bad interleaving by allocating the destination string first
before taking a raw pointer to an
RString*
.