Bug #20950: Use-after-free in ep in Proc#dup for ifunc procs

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED

[peterzhu2118 (Peter Zhu)]

GitHub PR: https://github.com/ruby/ruby/pull/12319

ifunc proc has the ep allocated in the data of the TypedData object. If an ifunc proc is duplicated, the ep points to the ep of the source object. If the source object is freed, then the ep of the duplicated object now points to a freed memory region. If we try to use the ep we could crash.

For example, the following script crashes:

p = { a: 1 }.to_proc
100.times do
  p = p.dup
  GC.start
  p.call
rescue ArgumentError
end

This commit changes ifunc proc to also duplicate the ep when it is duplicated.

[peterzhu2118 (Peter Zhu)]

• Status changed from Open to Closed

Applied in changeset git|92dd9734a967c20e628c8f77c5ce700058dcd58c.

---

Fix use-after-free in ep in Proc#dup for ifunc procs

[Bug #20950]

ifunc proc has the ep allocated in the cfunc_proc_t which is the data of
the TypedData object. If an ifunc proc is duplicated, the ep points to
the ep of the source object. If the source object is freed, then the ep
of the duplicated object now points to a freed memory region. If we try
to use the ep we could crash.

For example, the following script crashes:

p = { a: 1 }.to_proc
100.times do
  p = p.dup
  GC.start
  p.call
rescue ArgumentError
end

This commit changes ifunc proc to also duplicate the ep when it is duplicated.

[nagachika (Tomoyuki Chikanaga)]

Backporting only 92dd9734a967c20e628c8f77c5ce700058dcd58c into ruby_3_2 causes a VM_ASSERT() failure in vm_ep_in_heap_p_().
I believe there are additional changesets that should be backported beforehand.
Any suggestions would be greatly appreciated.