August 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:126279] [Ruby Feature#22231] Add `IO::Buffer#index`
by himura467 (Akito Shitara) 24 Aug '26

24 Aug '26

Issue #22231 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22231: Add `IO::Buffer#index` https://bugs.ruby-lang.org/issues/22231 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ## Use case `IO::Buffer` has no search primitive: no `#index`, no delimiter scan, no substring search. This matters for servers that hand request data to the application as zero-copy `IO::Buffer` views over their own socket read buffer. The zero-copy path ends at the first delimiter scan, such as splitting a query string on `&`, finding a multipart boundary, or scanning a header value, which is where request processing usually begins. The same applies to any protocol parser built on `IO::Buffer`: line framing, chunked transfer encoding, netstrings, length-prefixed records. All of them must find a delimiter before they can decide what to slice. Today there are two ways to do it, and both give up what the buffer was for: ```ruby buffer.get_string.index("&") # copies the whole region to find one offset i = 0 # no copy, but a method call per byte i += 1 while i < buffer.size && buffer.get_value(:U8, i) != 0x26 ``` Searching a 64 KiB body by copying it out is 3.7x slower than searching it in place, and allocates 66 KB per call. The byte loop allocates nothing but is roughly 1570x slower. ## Specification ```ruby buffer.index(object, offset = 0, length = size - offset) # => Integer or nil ``` `object` may be an `Integer` byte value (`0..255`), a `String`, or another `IO::Buffer`. ```ruby buffer = IO::Buffer.for("Hello World") buffer.index("World") # => 6 buffer.index("o".ord) # => 4 buffer.index(IO::Buffer.for("World")) # => 6 buffer.index("!") # => nil buffer.index("o", 5) # => 7 (absolute, not relative to offset) buffer.slice(6, 5).index("o") # => 1 (relative to the slice) ``` - Searching is byte-oriented; a `String`'s encoding is ignored. - An empty `object` matches at `offset`, as with `String#index`. - An `object` longer than the range returns `nil`. - An out-of-range `offset` or `length` raises `ArgumentError` (see below). Single-byte values use `memchr`. Longer values reuse `rb_memsearch`, the portable substring search that already backs `String#index`. ## Open questions ### Out-of-range `offset`/`length` raises, where `String#index` returns `nil`. All ten existing `(offset, length)` methods in `io_buffer.c` route through `io_buffer_validate_range` and raise, and the class never clamps. `String#index` also has no `length` parameter, so matching it does not settle what `length` should do; the Ruby-wide convention there is to clamp, as in `"hello".byteslice(0, 1000)`, which is what `IO::Buffer` declines to do elsewhere. I chose consistency within the class, and am happy to switch if the `String` reading is preferred. ### An `Integer` outside `0..255` raises, where `#clear` masks it. `buffer.clear(256)` fills with `0`, and `String#setbyte` masks too. Masking a value being searched for seems worse than masking one being written, since `index(256)` would quietly search for `\x00` and could return a match. ## Follow-ups `#rindex` for a reverse scan, and an `#each_until(delimiter)` framing iterator yielding successive delimited slices, in the same spirit as the vectorizable `#and!` / `#or!` / `#bit_count` family. Both build on `#index`, so this ticket is scoped to it. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126481] [Ruby Bug#22260] Ruby::Box: SIGSEGV when calling a method inside an isolated Proc defined at class/module body (RUBY_BOX=1)
by zonuexe (Kenta USAMI) 24 Aug '26

24 Aug '26

Issue #22260 has been reported by zonuexe (Kenta USAMI). ---------------------------------------- Bug #22260: Ruby::Box: SIGSEGV when calling a method inside an isolated Proc defined at class/module body (RUBY_BOX=1) https://bugs.ruby-lang.org/issues/22260 * Author: zonuexe (Kenta USAMI) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-24T10:31:23Z master 042e2bfd39) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary Under `RUBY_BOX=1`, any method call inside a Proc isolated by `Ractor.make_shareable` (or `Proc#isolate`) and defined at a class/module body crashes the VM: ```console $ RUBY_BOX=1 ruby -e 'module M; L = Ractor.make_shareable(->(*a){ Rational(*a) }); end; p M::L.call(3, 4)' -e:1: [BUG] Segmentation fault at 0x0000000000000000 $ ruby -e 'module M; L = Ractor.make_shareable(->(*a){ Rational(*a) }); end; p M::L.call(3, 4)' (3/4) ``` The Proc body does not matter (`a.to_s`, `1.zero?`, `String.name` all crash). A Proc defined inside a method body works. No user sub-boxes are involved. Backtrace: `rb_vm_search_method_slowpath` → `callable_method_entry_or_negative` → `search_method0`, faulting in `RCLASS_EXT_TABLE_LOOKUP_INTERNAL` with `box == NULL` (`box->box_object` sits at offset 0 of `rb_box_t`, hence address 0x0). ## Root cause A TOP/CLASS frame's env stores its box pointer in the SPECVAL slot; that is what `VM_ENV_BOX()` reads and `rb_current_box()` returns via `current_box_on_cfp()`. `env_copy()` (vm.c, called from `proc_isolate_env()`) rebuilds a local env with ```c else { ep[VM_ENV_DATA_INDEX_SPECVAL] = VM_BLOCK_HANDLER_NONE; } ``` so the copy keeps its frame type but loses its box. The first method lookup inside the isolated Proc then dereferences the NULL box. ## Proposed patch Copy the SPECVAL slot through for TOP/CLASS envs (patch attached, with a regression test in test/ruby/test_box.rb): ```c else if (VM_ENV_BOXED_P(src_ep)) { ep[VM_ENV_DATA_INDEX_SPECVAL] = src_ep[VM_ENV_DATA_INDEX_SPECVAL]; } ``` On master (042e2bfd39) the new test segfaults before the patch and passes after it; test_box.rb, test_proc.rb and test_ractor.rb stay green (288 tests, 0 failures). ## Context Hit by the [Rigor](https://github.com/rigortype/rigor) static analyzer, which calls `Ractor.make_shareable`d module-scope lambdas from worker Ractors. With the patch, analyzing the whole Redmine codebase under `RUBY_BOX=1` completes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115143] [Ruby master Bug#19970] Eval leaks callcache and callinfo objects on arm32 (linux)
by larsin (Lars Ingjer) 24 Aug '26

24 Aug '26

Issue #19970 has been reported by larsin (Lars Ingjer). ---------------------------------------- Bug #19970: Eval leaks callcache and callinfo objects on arm32 (linux) https://bugs.ruby-lang.org/issues/19970 * Author: larsin (Lars Ingjer) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [armv7l-linux-eabihf] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following script demonstrates a memory leak on arm 32 (linux): ``` ruby def gcdiff(n) GC.start if @last_gc_stat puts "GC.stat #{n} diff old_objects: #{GC.stat(:old_objects) - @last_gc_stat}" end @last_gc_stat = GC.stat(:old_objects) end def foo end 10.times do |i| 10_000.times do eval 'foo' end gcdiff(i) puts "Number of live objects: #{GC.stat(:heap_live_slots)}" puts "Memory usage: #{`ps -o rss= -p #{$$}`}" puts end ``` Output: ``` Number of live objects: 41303 Memory usage: 11900 GC.stat 1 diff old_objects: 20037 Number of live objects: 61317 Memory usage: 13604 GC.stat 2 diff old_objects: 20001 Number of live objects: 81317 Memory usage: 14880 GC.stat 3 diff old_objects: 20000 Number of live objects: 101317 Memory usage: 16596 GC.stat 4 diff old_objects: 20000 Number of live objects: 121317 Memory usage: 17248 GC.stat 5 diff old_objects: 20000 Number of live objects: 141317 Memory usage: 18760 GC.stat 6 diff old_objects: 20000 Number of live objects: 161317 Memory usage: 19540 GC.stat 7 diff old_objects: 20000 Number of live objects: 181317 Memory usage: 21752 GC.stat 8 diff old_objects: 20000 Number of live objects: 201317 Memory usage: 21828 GC.stat 9 diff old_objects: 20000 Number of live objects: 221317 Memory usage: 24896 ``` ObjectSpace.count_imemo_objects shows that imemo_callcache and imemo_callinfo are leaking. The issue does not occur on arm64 mac or x86_64 linux with the same ruby version. The issue has also been reproduced with the latest 3.2.2 snapshot (2023-09-30). -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126477] [Ruby Bug#22258] Update bundled json to >= 2.19.2 on ruby_4_0 (CVE-2026-33210)
by securepii-dev (Russell Penney) 24 Aug '26

24 Aug '26

Issue #22258 has been reported by securepii-dev (Russell Penney). ---------------------------------------- Bug #22258: Update bundled json to >= 2.19.2 on ruby_4_0 (CVE-2026-33210) https://bugs.ruby-lang.org/issues/22258 * Author: securepii-dev (Russell Penney) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The ruby_4_0 branch bundles json 2.18.0 (ext/json/lib/json/version.rb), which is affected by CVE-2026-33210 / GHSA-3m6g-2423-7cp3 (format string injection when parsing with allow_duplicate_key: false, fixed in json 2.19.2 — there is no patched 2.18.x release). All 4.0.0–4.0.6 releases and the official ruby:4.0 Docker images therefore ship a vulnerable json and are flagged by container scanners (AWS Inspector, Trivy, ECR scanning), which is problematic for compliance-scoped environments (e.g. PCI DSS). master has already synced json 3.0.0.rc1. Please sync json >= 2.19.2 to ruby_4_0 so it's included in 4.0.7. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124029] [Ruby Bug#21765] stop using the C runtime _read() on Windows
by YO4 (Yoshinao Muramatsu) 23 Aug '26

23 Aug '26

Issue #21765 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21765: stop using the C runtime _read() on Windows https://bugs.ruby-lang.org/issues/21765 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When creating an IO instance in Windows, the default data mode is text mode. In reality, the IO encoding conversion mechanism is not used when encoding conversion is not performed. Instead, the CRLF conversion provided by the C runtime's `_read()` is used. This is explicitly for speed. https://bugs.ruby-lang.org/issues/6401#note-4 As a trade-off, `SET_BINARY_MODE(fptr)` and `SET_BINARY_MODE_WITH_SEEK_CUR(fptr)` are used in various places within io.c, altering the state of the file descriptor. This made the flow of operations difficult to understand and changes hard to implement, especially for developers on other platforms. Additionally, the issues I recently reported were discovered while verifying the impact of modifying the CRLF conversion to utilize the encoding conversion mechanism. #21691 On Windows some of binary read functions of IO are not functional #21687 IO＃pos goes wrong after EOF character(ctrl-z) met #21634 Combining read(1) with eof? causes dropout of results unexpectedly on Windows. These issues arise because data read into the rbuf does not match the stream due to newline conversion, or because the buffer end and file position do not align when CTRLZ is detected. As a fix for Bug #21687, I created PR #15216. However, this relies on the internal behavior of the C runtime's `_read()` function, and it seems there is no way to avoid this dependency. **I propose removing the use of C runtime _read().** Reason for Proposal - The mismatch between rbuf and stream contents complicates io_unread() and makes maintenance difficult. - Changing the O_BINARY/O_TEXT state of the file descriptor in various places hinders understanding of the behavior and makes modifications difficult. Two methods to remove C runtime _read() while maintaining current behavior 1. Interpret CRLF and CTRLZ when reading rbuf within io.c. 1. Interpret CRLF and CTRLZ within the encoding conversion framework. My initial idea was to implement the second, using encoding conversion. However, this internally changes the read operation from rbuf to cbuf, resulting in a change to the behavior of ungetc. The proposal in Bug #21682 attempted to generalize this change to minimize its impact. https://bugs.ruby-lang.org/issues/21682 **This issue proposes the first method, crlf conversion during rbuf read.** Problems caused by inconsistencies between the rbuf and stream contents are avoided, and io_unread() becomes the same as on other platforms. Compared to implementing it as an encoding conversion, the advantage is that there is no change in behavior. On the other hand, since each read method in io.c requires individual handling, using encoding conversion results in more localized changes. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:115466] [Ruby master Bug#20020] Segfault running regexp match?
by andrea.salicetti＠gmail.com (Andrea Salicetti) 23 Aug '26

23 Aug '26

Issue #20020 has been reported by andrea.salicetti(a)gmail.com (Andrea Salicetti). ---------------------------------------- Bug #20020: Segfault running regexp match? https://bugs.ruby-lang.org/issues/20020 * Author: andrea.salicetti(a)gmail.com (Andrea Salicetti) * Status: Open * Priority: Normal * ruby -v: 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- **Ruby version** : ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] From `irb`, trying to call `match?` on this regular expression causes a segmentation falut: ```ruby irb(main):001:0> /^((a|c)|\s?){1,3}$/.match?('abc') => false irb(main):002:0> /^((a|c)|\s?){1,3}$/.match?('abc') (irb):2: [BUG] Segmentation fault at 0x000000061ba998e8 ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0037 p:---- s:0207 e:000206 CFUNC :match? c:0036 p:0006 s:0202 e:000201 EVAL (irb):2 [FINISH] c:0035 p:---- s:0199 e:000198 CFUNC :eval c:0034 p:0020 s:0191 e:000190 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/workspace.rb:119 c:0033 p:0153 s:0183 e:000181 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/context.rb:502 c:0032 p:0119 s:0170 e:000169 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:588 c:0031 p:0024 s:0164 e:000163 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:777 c:0030 p:0007 s:0158 e:000157 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:567 c:0029 p:0126 s:0153 e:000152 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:267 [FINISH] c:0028 p:---- s:0149 e:000148 CFUNC :loop c:0027 p:0005 s:0145 e:000144 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:249 [FINISH] c:0026 p:---- s:0142 e:000141 CFUNC :catch c:0025 p:0010 s:0137 e:000136 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:248 c:0024 p:0050 s:0132 E:000dd8 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:566 c:0023 p:0003 s:0127 e:000126 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:500 [FINISH] c:0022 p:---- s:0124 e:000123 CFUNC :catch c:0021 p:0050 s:0119 E:000d50 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:499 c:0020 p:0069 s:0113 e:000112 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:421 c:0019 p:0012 s:0107 e:000106 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/irb-1.6.2/exe/irb:11 [FINISH] c:0018 p:---- s:0104 e:000103 CFUNC :load c:0017 p:0078 s:0099 e:000098 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/bin/irb:25 [FINISH] c:0016 p:---- s:0094 e:000093 CFUNC :load c:0015 p:0064 s:0089 e:000088 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:58 c:0014 p:0050 s:0083 e:000082 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:23 c:0013 p:0034 s:0078 e:000077 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:492 c:0012 p:0054 s:0073 e:000072 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/command.rb:28 c:0011 p:0040 s:0065 e:000064 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/invocation.rb:127 c:0010 p:0213 s:0058 e:000057 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor.rb:527 c:0009 p:0008 s:0045 e:000044 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:34 c:0008 p:0044 s:0040 e:000039 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/base.rb:584 c:0007 p:0022 s:0033 e:000032 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:28 c:0006 p:0042 s:0028 e:000027 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.22/exe/bundle:37 c:0005 p:0007 s:0022 e:000021 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/friendly_errors.rb:117 c:0004 p:0108 s:0017 E:0019b8 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.22/exe/bundle:29 [FINISH] c:0003 p:---- s:0013 e:000012 CFUNC :load c:0002 p:0081 s:0008 E:000220 EVAL /Users/andreasalicetti/.rbenv/versions/3.2.2/bin/bundle:25 [FINISH] c:0001 p:0000 s:0003 E:001980 DUMMY [FINISH] ``` Sometimes this happens the very first time I try to execute the command, some other times I have to try a couple of times to see that Segmentation Fault (but usually within the first 5 attempts). ---Files-------------------------------- ruby-2023-11-23-175410.ips (20.2 KB) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:124335] [Ruby Bug#21798] `bundle install` command fails if touches `$LOAD_PATH` on `Ruby::Box` enabled
by unasuke (Yusuke Nakamura) 23 Aug '26

23 Aug '26

Issue #21798 has been reported by unasuke (Yusuke Nakamura). ---------------------------------------- Bug #21798: `bundle install` command fails if touches `$LOAD_PATH` on `Ruby::Box` enabled https://bugs.ruby-lang.org/issues/21798 * Author: unasuke (Yusuke Nakamura) * Status: Open * ruby -v: 4.0.0-preview3 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## How to reproduce ```dockerfile FROM ruby:4.0.0-preview3-trixie WORKDIR /ruby_box_test RUN bundle gem foo --test=minitest WORKDIR /ruby_box_test/foo RUN head -n 10 foo.gemspec # PASS RUN bundle install # PASS RUN RUBY_BOX=1 bundle install RUN sed --in-place \ --expression='2i lib=File.expand_path("../lib", __FILE__)\n$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)' \ foo.gemspec RUN sed --in-place \ --expression='s/require_relative "lib\/foo\/version"/require "foo\/version"/' \ foo.gemspec RUN head -n 10 foo.gemspec # PASS RUN bundle install # FAIL RUN RUBY_BOX=1 bundle install ``` This script fails. ``` /usr/local/bin/ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. [!] There was an error while loading `foo.gemspec`: cannot load such file -- foo/version. Bundler cannot continue. # from /ruby_box_test/foo/foo.gemspec:5 # ------------------------------------------- # > require "foo/version" # # ------------------------------------------- Error: building at STEP "RUN RUBY_BOX=1 bundle install": while running runtime: exit status 14 ``` Head of the gemspec file is this. ```ruby # frozen_string_literal: true lib=File.expand_path("../lib", __FILE__) $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib) require "foo/version" Gem::Specification.new do |spec| # ..snip.. end ``` # misc I found this behavior when `RUBY_BOX=1 bundle exec rake spec` on `https://github.com/itamae-kitchen/itamae`. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126083] [Ruby Bug#22195] `IO::Buffer` read after free silently returns empty data instead of raising
by himura467 (Akito Shitara) 23 Aug '26

23 Aug '26

Issue #22195 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22195: `IO::Buffer` read after free silently returns empty data instead of raising https://bugs.ruby-lang.org/issues/22195 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Reading from an `IO::Buffer` after calling `#free` does not raise. It behaves like an empty buffer, and `#valid?` still returns `true`: ```ruby buffer = IO::Buffer.for("Hello World") buffer.free buffer.valid? # => true buffer.get_string # => "" (no error) ``` ## Why this looks like an unintended regression Originally (https://github.com/ruby/ruby/commit/e30920354f, Ruby 3.1–3.3), accessing a freed buffer raised `IO::Buffer::AllocationError` ("The buffer is not allocated!"). https://github.com/ruby/ruby/commit/c5cf4d4e12 made zero-length buffer operations succeed instead of raising, for [Bug #19542] and [Bug #18805]. Since a freed buffer also has `base == NULL, size == 0`, it was caught in the same code path and stopped raising too. Neither ticket mentions freed buffers, so this appears to be an accidental side effect rather than a decision. Note that the rdoc of `#free` still promises that access after free raises. ## Proposal How about marking a buffer as invalidated when it is explicitly freed (`#free` / `rb_io_buffer_free`), so that: * `#valid?` returns `false`. * Any byte access raises `IO::Buffer::InvalidatedError` or `IO::Buffer::AllocationError`. * `#resize` re-allocates and clears the mark, as `#free`'s rdoc promises ("You can resize a freed buffer to re-allocate it"). * The zero-length buffer semantics from https://github.com/ruby/ruby/pull/9532 are preserved: `IO::Buffer.new(0)`, `resize(0)` and zero-length slices remain valid and readable. I'm not sure which exception class is preferable: `IO::Buffer::InvalidatedError` is consistent with how invalidated slices already behave and with `#valid?` returning `false`, while `IO::Buffer::AllocationError` restores the pre-3.4 behavior. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:125811] [Ruby Bug#22125] IO::Buffer triggers use-after-free when it's freed/resized during enumeration
by hanazuki (Kasumi Hanazuki) 22 Aug '26

22 Aug '26

Issue #22125 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #22125: IO::Buffer triggers use-after-free when it's freed/resized during enumeration https://bugs.ruby-lang.org/issues/22125 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T09:56:24Z master 55945e5c98) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The block passed to `IO::Buffer#each` can free or resize the receiver (or its parent buffer when the reciver is a slice), which invalidates the memory region being iterated. The next iteration causes use-after-free. repro: ``` ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.resize(20) }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b.free }' # No use-after-free but I think those should be errors too ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b1.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.transfer }' ``` same for `#each_byte`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121507] [Ruby Bug#21212] IO::Buffer can be freed while its slice is locked
by hanazuki (Kasumi Hanazuki) 22 Aug '26

22 Aug '26

Issue #21212 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21212: IO::Buffer can be freed while its slice is locked https://bugs.ruby-lang.org/issues/21212 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * 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 ---------------------------------------- ```ruby 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 ``` -- https://bugs.ruby-lang.org/

3 3