Use-after-free allowed with autorelease block

[byteit101]

JRuby (safe):

> x = FFI::MemoryPointer.new(:int, 20_000_000){|mm| nil }.write_array_of_int([12]*2_000_00)
Traceback (most recent call last):
        2: from (irb):11:in `evaluate'
        1: from org/jruby/ext/ffi/AbstractMemory.java:1555:in `write_array_of_int32'
RuntimeError (attempting to access freed memory)
> x.read_int
Traceback (most recent call last):
        2: from (irb):12:in `evaluate'
        1: from org/jruby/ext/ffi/AbstractMemory.java:1555:in `write_array_of_int32'
RuntimeError (attempting to access freed memory)
>

MRI (affected)

> x = FFI::MemoryPointer.new(:int, 20_000_000){|mm| nil }.write_array_of_int([12]*2_000_00)
> x.read_int
(irb):20: [BUG] Segmentation fault at 0x00007f25833b4010
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]
                                                 
-- Control frame information -----------------------------------------------
c:0022 p:---- s:0109 e:000108 CFUNC  :read_int32 
# snip many lines of the crash...

Using FFI 1.15.5

Caveat: I know this is possible with a manual LibC.free(ptr) where FFI isn't aware of the status of the pointer, but I didn't expect this SEGV with MemoryPointer autorelease blocks. I was pleased that JRuby blocks this by default.

I have long been frustrated that MemoryPointer.new { 5 } returns not 5, but self, like MemoryPointer.new, and unlike the common Ruby-ism of returning the block argument return value. I'd love to see that changed, which would mostly take mostly take care of this use-after-free, though that may be a separate, API-breaking issue in and of itself. As long as the block returns something that doesn't allow write access, like the JRuby implementation, that should solve this issue.