Issue #21438 has been updated by byroot (Jean Boussier). Status changed from Open to Closed The remaining issue was fixed in 055fef00a1c27fdc8293114dc134ca7910b1dc79. Backport PRs: - 3.4: https://github.com/ruby/ruby/pull/13637 - 3.3: https://github.com/ruby/ruby/pull/13638 Note that the bug while possible is quite unlikely on older branches as it requires 9 ivars instead of 4, so maintainers should feel free to not backport. ---------------------------------------- Bug #21438: use-after-free when resizing exivars https://bugs.ruby-lang.org/issues/21438#change-113776 * Author: byroot (Jean Boussier) * Status: Closed * Backport: 3.2: WONTFIX, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Here's a semi-reliable reproduction: ```ruby objs = 10_000.times.map do a = [] a.instance_variable_set(:@a, 1) a end GC.stress = true GC.auto_compact = true steps = 1000.times.map do a = [] a.instance_variable_set(:@a, 1) a.instance_variable_set(:@b, 2) a.instance_variable_set(:@c, 3) a.instance_variable_set(:@d, 4) a.instance_variable_set(:@e, 5) a.instance_variable_set(:@f, 6) a.instance_variable_set(:@g, 7) a.instance_variable_set(:@h, 8) # resize a.instance_variable_set(:@i, 9) a.instance_variable_set(:@j, 10) a end objs.clear GC.stress = false GC.auto_compact = false ``` The Exivar codepath uses `st_update` and allocate within the codebase. If GC trigger, it may remove entires from the table, or delete+insert in case of compaction, and this can trigger a table rebuild of the generic fields st_table in the middle of calling the st_update callback. This can cause entries to be reallocated or rearranged and the update to be for the wrong entry. Auto compaction isn't strictly required to trigger the bug, but makes it more likely. -- https://bugs.ruby-lang.org/