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

[ruby-core:127078] [Ruby Feature#12831] /\X/ (extended grapheme cluster) can't pass unicode.org's GraphemeBreakTest
by Mrlaura (QUANG NGUYEN) 12 Oct '26

12 Oct '26

Issue #12831 has been updated by Mrlaura (QUANG NGUYEN). Thanks to everyone who investigated and fixed this grapheme segmentation issue. One related detail worth highlighting is that correct grapheme segmentation doesn't automatically guarantee Unicode-equivalent string comparisons. For example, "é" (U+00E9) and "e" + U+0301 are both single grapheme clusters, but their underlying code points differ. For text matching or Levenshtein distance over user-perceived characters, it's often useful to normalize both strings to NFC before splitting them into grapheme clusters. It's also important to use a GraphemeBreakTest version matching the Unicode rules implemented by the Ruby version being tested. A related technical discussion is available here: https://www.levenshtein.net/unicode-and-grapheme-safe-levenshtein For transparency, I contribute to that reference. Thanks again for improving Ruby's Unicode support! ---------------------------------------- Feature #12831: /\X/ (extended grapheme cluster) can't pass unicode.org's GraphemeBreakTest https://bugs.ruby-lang.org/issues/12831#change-119477 * Author: mtsmfm (Fumiaki Matsushima) * Status: Closed * Assignee: naruse (Yui NARUSE) ---------------------------------------- I'm trying to replace Rails's grapheme implementation (http://api.rubyonrails.org/classes/ActiveSupport/Multibyte/Unicode.html#met…) with Ruby's extended grapheme cluster (/X/). https://github.com/rails/rails/issues/26743 I noticed that Ruby's grapheme cluster can't pass unicode.org's GraphemeBreakTest. Following test script will fail on Ruby 2.2/2.3 ~~~ ruby require 'rubygems' require 'open-uri' require 'test/unit' UNICODE_VERSION = if Gem::Version.new(RUBY_VERSION) >= Gem::Version.new("2.3.0") "8.0.0" else "7.0.0" end class TestGrapheme < Test::Unit::TestCase # https://github.com/rails/rails/blob/v5.0.0.1/activesupport/test/multibyte_g… def test_breaks each_line_of_break_tests do |*cols| *clusters, comment = *cols string = clusters.map {|c| c.pack("U*") }.join assert_equal clusters, string.scan(/\X/).map(&:codepoints), comment end end def each_line_of_break_tests(&block) lines = 0 max_test_lines = 0 # Don't limit below 21, because that's the header of the testfile URI.parse("http://www.unicode.org/Public/#{UNICODE_VERSION}/ucd/auxiliary/GraphemeBrea…").open do |f| until f.eof? || (max_test_lines > 21 && lines > max_test_lines) lines += 1 line = f.gets.chomp! next if line.empty? || line.start_with?("#") cols, comment = line.split("#") # Cluster breaks are represented by ÷ clusters = cols.split("÷").map { |e| e.strip }.reject { |e| e.empty? } clusters = clusters.map do |cluster| # Codepoints within each cluster are separated by × codepoints = cluster.split("×").map { |e| e.strip }.reject { |e| e.empty? } # codepoints are in hex in the test suite, pack wants them as integers codepoints.map { |codepoint| codepoint.to_i(16) } end # The tests contain a solitary U+D800 <Non Private Use High # Surrogate, First> character, which Ruby does not allow to stand # alone in a UTF-8 string. So we'll just skip it. next if clusters.flatten.include?(0xd800) clusters << comment.strip yield(*clusters) end end end end ~~~ https://gist.github.com/mtsmfm/38f46882c3d4ccde35c269594fc24ebc I found an issue on Onigmo (https://github.com/k-takata/Onigmo/issues/46) but I couldn't on bugs.ruby-lang.org so I created this ticket. I'm unfamiliar with grapheme so please tell me if I get something wrong. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126744] [Ruby Bug#22326] heap buffer overflow in array.values_at()
by danielchong (Daniel Chong) 12 Oct '26

12 Oct '26

Issue #22326 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22326: heap buffer overflow in array.values_at() https://bugs.ruby-lang.org/issues/22326 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I discovered a heap buffer overflow in array.values_at(). I believe the root issue/potential fix is similar to #22325, but the code paths are distinct. PoC: ``` class bad < Numeric def initialize(v); @v = v; end def val; @v; end def <=>(o); @v <=> (o.is_a?(bad) ? o.val : o); end def to_int; $a.clear; @v; end def to_i; @v; end def coerce(o); [o, @v]; end end $a = (1..3000).to_a $a.values_at(Range.new(bad.new(2900), bad.new(2950))) ``` asan output (truncated): ``` ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 408 ... #3 ary_memcpy0 array.c:354 #4 rb_ary_cat array.c:1417 #5 append_values_at_single array.c:3970 #6 rb_ary_values_at array.c:4096 ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:127061] [Ruby Bug#22423] String#initialize(encoding:) stores an inflated capacity and writes past the malloc'd buffer on append (rb_str_init termlen double-adjust)
by sushie (Bug Bounty) 12 Oct '26

12 Oct '26

Issue #22423 has been reported by sushie (Bug Bounty). ---------------------------------------- Bug #22423: String#initialize(encoding:) stores an inflated capacity and writes past the malloc'd buffer on append (rb_str_init termlen double-adjust) https://bugs.ruby-lang.org/issues/22423 * Author: sushie (Bug Bounty) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Description ----------- `String#initialize` with `encoding:` and `capacity:` keywords stores a capacity that is LARGER than the buffer actually allocated, so later in-place growth (`<<` / `concat`) writes past the end of the malloc'd region. Root cause: in `rb_str_init` (string.c) the buffer is sized with the NEW encoding's terminator length, the source bytes are copied, and then `rb_enc_associate(str, enc)` re-adjusts `aux.capa` against the OLD encoding's terminator length (via `rb_str_change_terminator_length`). When the source string's encoding has a longer terminator (UTF-16/32 -> UTF-8), the stored capacity ends up larger than the allocation. This is the same construct that was fixed in `str_shared_replace` by commit 323c1df196 ("[Bug #22387] Fix termlen in str_shared_replace"); `rb_str_init` has the identical pattern and is still unchanged on master (verified byte-identical between the v4_0_7 tag and current master). Reproducer ---------- Uses only the fiddle stdlib, which ships with the default distribution (the library path below is the homebrew macOS layout; adjust to your install): require "fiddle" h = Fiddle::Handle.new("/opt/homebrew/opt/ruby/lib/libruby.4.0.dylib") $rb_str_capacity = Fiddle::Function.new(h["rb_str_capacity"], [Fiddle::TYPE_VOIDP], Fiddle::TYPE_SIZE_T) def capa(s) = $rb_str_capacity.call(Fiddle.dlwrap(s)) S = Class.new(String) orig = ("\u{30AF}" * 5).encode("UTF-16LE") # 10 bytes, 2-byte terminator orig32 = ("\u{30AF}" * 5).encode("UTF-32LE") # 20 bytes, 4-byte terminator a = S.new(orig, encoding: "UTF-8", capacity: 200) b = S.new(orig32, encoding: "UTF-8", capacity: 200) puts "UTF-16LE -> UTF-8 : capa=#{capa(a)}" puts "UTF-32LE -> UTF-8 : capa=#{capa(b)}" a << ("x" * 191) puts "after append 191B : len=#{a.bytesize} capa=#{capa(a)}" Actual output (4.0.7; identical behavior on master): UTF-16LE -> UTF-8 : capa=201 UTF-32LE -> UTF-8 : capa=203 after append 191B : len=201 capa=201 The buffer is allocated as `capacity + termlen(UTF-8)` = 201 bytes, but the stored capacity is 201 (UTF-16LE input) / 203 (UTF-32LE input). Appending 191 bytes grows the string to 201 bytes, which does not exceed the stored capacity, so no reallocation happens and `TERM_FILL` writes the NUL terminator at index 201 - one byte past the 201-byte malloc region (up to 3 bytes past for the UTF-32LE case). Worst case: `capacity: 207` allocates 208 bytes (207 + 1), stores capacity 210, and appending 207 bytes to the 20 existing content bytes writes through index 227 - 19 bytes past the allocation, into adjacent heap memory. Expected behavior ----------------- `rb_str_capacity` should never exceed the allocation (`capacity + termlen(new encoding)`), and in-place growth must reallocate before writing past the buffer. Proposed fix ------------ In `rb_str_init`, associate the new encoding with `rb_enc_raw_set` instead of `rb_enc_associate`, so the capacity is not re-adjusted against the old terminator length (mirroring 323c1df196); alternatively reorder so the buffer is sized against the encoding that is actually set. Suggested change in string.c `rb_str_init`: rb_enc_raw_set(str, enc); instead of `rb_enc_associate(str, enc)`. Affected versions ----------------- All releases up to and including 4.0.7, and current master. Note ---- Reported initially through the Ruby HackerOne program; filing here per the maintainers' suggestion so the fix can land and be backported. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126882] [Ruby Bug#22391] Fix propagation of `ERRNO` in `rb_io_maybe_wait`.
by ioquatix (Samuel Williams) 12 Oct '26

12 Oct '26

Issue #22391 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22391: Fix propagation of `ERRNO` in `rb_io_maybe_wait`. https://bugs.ruby-lang.org/issues/22391 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- When a write returns `EAGAIN`, we call `rb_io_wait()`: io_write() io_fwrite() io_binwrite() io_binwrite_string() io_binwrite_string_internal() ... rb_io_maybe_wait_writable() rb_io_maybe_wait() return rb_io_wait(io, events, timeout) if this wait also fails, it bubbles up to io_write() which reports it: io_write() rb_sys_fail_on_write() rb_syserr_new_path_in() rb_syserr_new_path(errno, ...) `rb_syserr_new_path_in` (after macro resolution) checks for a 0 error code and aborts in that case: if (n == 0) { const char *s = !NIL_P(path) ? RSTRING_PTR(path) : ""; if (!func_name) func_name = "(null)"; rb_bug("rb_sys_fail_path_in(%s, %s) - errno == 0", func_name, s); } Unfortunately, `rb_io_wait()` can invoke the fiber scheduler, running arbitrary code that can clobber `errno` and trigger this `rb_bug()`. Fix this by preserving `errno` explicitly across the `rb_io_wait()` call. https://github.com/ruby/ruby/pull/19121 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126878] [Ruby Bug#22388] Use-after-free when an Enumerable retains its `each` block
by nobu (Nobuyoshi Nakada) 12 Oct '26

12 Oct '26

Issue #22388 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22388: Use-after-free when an Enumerable retains its `each` block https://bugs.ruby-lang.org/issues/22388 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Some `Enumerable` methods pass a pointer to stack-allocated state to `rb_block_call`. If an implementation of `each` retains the given block and invokes it after the `Enumerable` method has returned, the callback accesses invalid stack memory. This affects `Enumerable#min(n)`, `#max(n)`, `#min_by(n)`, and `#max_by(n)`. It also affects `Enumerable#sum`. The following example reproduces the problem: ````ruby class DeferredEach include Enumerable attr_reader :each_block def each(&block) @each_block = block end end enum = DeferredEach.new enum.min(2) GC.start enum.each_block.call(1) ```` The same problem exists in the other methods: ````ruby %i[min max min_by max_by].each do |method| enum = DeferredEach.new enum.public_send(method, 2) { |x| x } GC.start enum.each_block.call(1) end ```` `Enumerable#sum` can be reproduced as follows: ````ruby enum = DeferredEach.new enum.sum { |x| x * 2 } GC.start enum.each_block.call(1) ```` Depending on the stack contents and GC timing, these examples may crash, raise an unrelated exception, or appear to work. The behavior is undefined because the retained callback refers to state whose lifetime ended when the original method returned. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126871] [Ruby Bug#22387] str_shared_replace incorrectly recalculates termlen
by rwstauner (Randy Stauner) 12 Oct '26

12 Oct '26

Issue #22387 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22387: str_shared_replace incorrectly recalculates termlen https://bugs.ruby-lang.org/issues/22387 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: REQUIRED ---------------------------------------- This ruby snippet crashes under ASan ```ruby s = ("\u{30AF}" * 7).encode("UTF-16LE").b s.force_encoding("UTF-16LE") s.encode!("UTF-8") # 21 bytes in a 22-byte malloc, capa now claims 22 s << "x" # fits, per capa, then NUL terminator written at [22] ``` str_shared_replace uses rb_enc_associate which recalculates termlen based on the old str even though the termlen of the new str was already used for the copy. We can just switch that to rb_enc_raw_set to fix. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:126531] [Ruby Feature#22274] Make `IO::Buffer` no longer experimental.
by ioquatix (Samuel Williams) 12 Oct '26

12 Oct '26

Issue #22274 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #22274: Make `IO::Buffer` no longer experimental. https://bugs.ruby-lang.org/issues/22274 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- `IO::Buffer` was introduced in Ruby 3.1 by Feature #18020 as an experimental API. It provides an efficient buffer abstraction for fiber scheduler I/O, zero-copy operations, binary protocol implementations, and access from native extensions. Since then, the API has seen several Ruby releases of real-world use and substantial development. Ruby 4.1 now has cohesive semantics for buffer ownership and lifecycle, slicing, locking, string and file mappings, MemoryView integration, and single-transfer I/O operations. I propose making both the Ruby and public C interfaces of `IO::Buffer` non-experimental in Ruby 4.1. This would involve: * Removing the allocation-time experimental warning. * Removing the experimental status from the class documentation. * Removing `RB_IO_BUFFER_EXPERIMENTAL` from the public C header. * Removing warning suppression that is only required because `IO::Buffer` is experimental. * Updating NEWS to describe `IO::Buffer` as stable. `RUBY_IO_BUFFER_VERSION` would remain available for compile-time feature detection as the interface continues to evolve. Before stabilizing the interface, I would particularly appreciate feedback from JRuby and TruffleRuby maintainers. Related work: * Original proposal: https://bugs.ruby-lang.org/issues/18020 * CRuby implementation PR: https://github.com/ruby/ruby/pull/18486 * TruffleRuby implementation: https://github.com/truffleruby/truffleruby/pull/4248 * JRuby implementation: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/Rub… * JRuby file-mapping issue: https://github.com/jruby/jruby/issues/8714 -- https://bugs.ruby-lang.org/

8 18

[ruby-core:124714] [Ruby Bug#21870] Regexp: Warnings when using multiple non-overlapping \p{...} classes
by jneen (Jeanine Adkisson) 11 Oct '26

11 Oct '26

Issue #21870 has been reported by jneen (Jeanine Adkisson). ---------------------------------------- Bug #21870: Regexp: Warnings when using multiple non-overlapping \p{...} classes https://bugs.ruby-lang.org/issues/21870 * Author: jneen (Jeanine Adkisson) * Status: Open * ruby -v: 4.0.0, 4.0.1, earlier versions to a lesser extent * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby $VERBOSE = true # warning: character class has duplicated range: /[\p{Word}\p{S}]/ regex = /[\p{Word}\p{S}]/ ``` As far as I can tell this is a perfectly valid and non-overlapping set of unicode properties, but I am still being spammed with warnings. Using `/(\p{Word}|\p{S})/` is kind of a workaround, but it is slower. -- https://bugs.ruby-lang.org/

11 25

[ruby-core:127065] [Ruby Bug#22425] shield frozen tests in test_rubyoptions.rb from externally defined RUBYOPT
by zenspider (Ryan Davis) 11 Oct '26

11 Oct '26

Issue #22425 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #22425: shield frozen tests in test_rubyoptions.rb from externally defined RUBYOPT https://bugs.ruby-lang.org/issues/22425 * Author: zenspider (Ryan Davis) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- fixed in https://github.com/ruby/ruby/pull/19294 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126653] [Ruby Bug#22305] Ruby::Box: statically linked prism loads in only one box
by hsbt (Hiroshi SHIBATA) 11 Oct '26

11 Oct '26

Issue #22305 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22305: Ruby::Box: statically linked prism loads in only one box https://bugs.ruby-lang.org/issues/22305 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-10T03:20:50Z master fe58143f12) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, the statically linked prism can be required in only one box. The second box raises `LoadError`. ``` $ RUBY_BOX=1 ruby --disable-gems -e 'require "prism"; p Ruby::Box.new.eval(%q{require "prism"; Prism::VERSION})' lib/prism.rb:161:in 'Kernel#require': cannot load such file -- prism/prism (LoadError) ``` Swapping the order fails the same way. `--disable-gems` matters here. With a prism gem installed, each box dlopens its own copy of the gem's `prism.bundle` and the problem disappears, which makes it easy to miss. There is no `prism.so` file. `prism_init.c:8` registers the name `prism/prism.so` with `ruby_init_ext`, pointing at the `Init_prism` already linked into the interpreter, so `require "prism/prism"` behaves as if it had loaded an extension. That entry can be used only once (`load.c:1280`). The parser itself works in every box, but loading a gem that requires prism internally, such as error_highlight, is enough to break it in every box other than the one that loaded prism first. The obvious fixes do not hold. Running the init in every box leaves one set of C globals pointing at whichever box ran it last, so nodes parsed in the other box fail `is_a?(Prism::ProgramNode)`. That trades the `LoadError` for a silent type mismatch. Initializing prism before the boxes exist and marking the feature provided makes the `require "prism/prism"` inside an activated prism gem a no-op, so the gem's Ruby half binds to the interpreter's C half. The `ruby-lsp` benchmark fails on exactly that. I see three designs and would like one chosen. The first treats prism as an extension. The Ruby binding is built as its own shared object while the parser stays static, so each box dlopens its own copy the way it already does for other extensions. The same principle would also fix every extension under `--with-static-linked-ext`. It changes the build and needs symbol exports on Windows. The second treats it as part of the interpreter, like `String`. It is initialized once before the boxes and every box shares its classes. `defined?(Prism)` becomes true without a `require`, it adds 339 classes at boot, and a prism gem can no longer take over. The third changes Box instead. One way would be to share a statically linked extension across boxes like a builtin class without marking it provided, so that a prism gem can still take over, though I am not sure that fits where Box is heading. ## How prism came to ship this way #19741 mirrored YARP into ruby/ruby together with its Ruby API and registered the native part with `ruby_init_ext`. #19772 then moved toward mirroring only the C implementation and leaving the Ruby API to a bundled prism gem (#19772#note-29), and #19900 stated that prism would be a bundled gem with a native extension. The static registration from #19741 survived the rename, so prism ships as a default gem linked into the interpreter, and that registration is what fails here. The native extension #19900 described works in every box, and the first design comes down to it. The second design has a history of its own. Matz first approved a built-in `Ruby::Parser` that no gem could replace (#19772#note-9), and the same idea came back as a gem-independent `Ruby::Node` for `Proc#syntax_tree` (#21795#note-1). There Matz required that the parser that ran the program and the parser that returns the tree be the same (#21795#note-19), and the feature settled on the default gem prism for that. That is exactly the prism a second box cannot load, which also blocks the way #21795#note-38 suggested Box could eventually expose the interpreter's own parser. -- https://bugs.ruby-lang.org/

5 7