Bug #21212: IO::Buffer can be freed while its slice is locked

• Status: Open
• Assignee: ioquatix (Samuel Williams)
• Target version: -
• ruby -v: ruby 3.5.0dev (2025-04-01T16:11:01Z master 30e5e7c005) +PRISM [x86_64-linux]
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN

[hanazuki (Kasumi Hanazuki)]

buffer = IO::Buffer.new(100)
slice = buffer.slice

buffer.locked do
  buffer.free rescue p $!  #=> IO::Buffer::LockedError (expected)
end

slice.locked do
  p slice.locked?  #=> true (expected)
  p buffer.locked?  #=> false (what should this be?)

  slice.free rescue p $!  #=> IO::Buffer::LockedError (expected)

  buffer.free  # Should we allow this?

  slice.set_value(:U8, 0, 42)  # raises IO::Buffer::InvalidatedError (surprising!)
end

[hanazuki (Kasumi Hanazuki)]

I think the problem is that each IO::Buffer slice manages the lock state independently, and so the root IO::Buffer cannot know whether the memory is locked by one of its slices.

If the memory is being accessed by a native function like rb_io_buffer_read when the buffer is freed, this may be a loophole to trigger use-after-free.

# Assume this file is on a very slow device such as NFS.
io = File.open('/mnt/slowfs/slow')

buffer = IO::Buffer.new(100)
slice = buffer.slice

t1 = Thread.new do
  puts "start reading"
  slice.read(io)  # This takes too long.
  # If the memory backing the slice is freed already, read can write into invalid address.
  puts "finished reading"
end

t2 = Thread.new do
  sleep 0.5  # This waits for the read to begin.
  buffer.free  # This may free the buffer before the read finishes.
  puts "freed buffer"
end

t1.join
t2.join

[byroot (Jean Boussier)]

• Assignee set to ioquatix (Samuel Williams)