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

[ruby-core:126675] [Ruby Feature#22309] Allow super in a module method to work if method was called by refinement method super
by jeremyevans0 (Jeremy Evans) 10 Oct '26

10 Oct '26

Issue #22309 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #22309: Allow super in a module method to work if method was called by refinement method super https://bugs.ruby-lang.org/issues/22309 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- Ruby started allowing refinements of modules in 2.4. However, there was one limitation, which is that while the refinement method could call `super` to call the module method, the module method could not call `super`, because it did not have enough information to determine the appropriate ancestor. This limitation was known at the time and was accepted when module refinements were accepted in #12534. As discussed in #22071, `super` wasn't actually prohibited in the module method, it just used the incorrect method lookup, looking for a super method in `BasicObject`. After discussion in #22071, I fixed this to use an explicit exception for this case, so an error was was raised for it. While that addressed the incorrect super method lookup issue, it was an unsatisfying conclusion. I kept thinking about ways to actually fix the issue. My initial idea was to use a separate `T_ICLASS` for the module being refined in every class ancestry chain where it could be called via refinement `super`. However, that approach would result in a large amount of complexity, as well as potentially significant additional memory. I am instead proposing an alternative approach which relies on the fact that when we call `super` in the module method, we know that the current method is a module method, and that the previous method in the call stack is a refinement method. We can walk up the call stack to find the refinement method, look at the previous method calling that to determine the class to use for the super lookup. Note that the previous method may use a different receiver/method, in which case we start with the receiver's class. There are cases where we need to do this multiple times, if there are multiple refinements or multiple modules being refined that have already called super to reach this point. I'm not sure this alternative approach works in all cases, but I have gotten it to work every case I've tried: * Module and refinement appears multiple times in the ancestor chain * `super` calls both directly in method as well as in nested blocks in method * Both refinement method and module method are bmethods * Refinement refines multiple modules and both modules are involved in the same super call chain * Multiple refinements of the same module method * Use of ZSUPER aliases in the super call chain * The `super` call in the module method is not found, and `NoMethodError` is raised correctly We want the behavior of module refinement `super` to be consistent, so in addition to fixing `super` itself, we also need to fix `defined?(super)` as well as `Method#super_method` and `UnboundMethod#super_method`. `defined?(super)` is fixed by sharing the lookup that `super` now uses. However, `Method#super_method` and `UnboundMethod#super_method` require a different approach. Thankfully, `struct METHOD` already has a member named `iclass` that is used to implement `#super_method`. So we just need to make adjustments to the setting of the `iclass` member for `#super_method` to work. Simple example: ```ruby module M def m = [:M, *super] end class C prepend M def m = :C end module R refine M do def m = [:R, *super] end end using R C.new.m # => [:R, :M, :C] ``` I've submitted a pull request to implement this: https://github.com/ruby/ruby/pull/18797 -- https://bugs.ruby-lang.org/

3 12

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

09 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/

3 2

[ruby-core:126553] [Ruby Bug#22284] Passing an object with to_int to curry as its arity causes problems with LLP64.
by YO4 (Yoshinao Muramatsu) 09 Oct '26

09 Oct '26

Issue #22284 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #22284: Passing an object with to_int to curry as its arity causes problems with LLP64. https://bugs.ruby-lang.org/issues/22284 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: master * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The proc_curry function in proc.c is affected by differences in behavior caused by the int size in FIX2INT. As a result, depending on the arguments, curry may not function correctly on Windows. ``` method(:puts).curry(1r).call(42) => #<Proc:0x0000000005e06c58 (lambda)> (Windows) => 42 (others) ``` The same thing happens in gems/src/rbs/test/stdlib/Proc_test.rb:113. It also triggers an assertion in a debug build on windows. ``` irb(main):001> method(:puts).curry(1r).call(42) S:\git\ruby\ruby\include\ruby/internal/arithmetic/long.h:192: Assertion Failed: rbimpl_fix2long_by_shift:RB_FIXNUM_P(x) ...(snip) -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FF82F2E0404] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF82C53C11F] S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_print_backtrace+0x3e) [0x00007FFF45D706CA] S:\git\ruby\ruby\vm_dump.c:1137 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_vm_bugreport+0x288) [0x00007FFF45D70958] S:\git\ruby\ruby\vm_dump.c:1482 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_assert_failure_detail+0xbb) [0x00007FFF45C05557] S:\git\ruby\ruby\error.c:1227 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_assert_failure+0x12) [0x00007FFF45C0549A] S:\git\ruby\ruby\error.c:1202 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(proc_curry+0xfa) [0x00007FFF45D48426] S:\git\ruby\ruby\proc.c:4614 ...(snip) ``` proc.c:4614 has this ``` sarity = FIX2INT(arity); ``` FIX2INT is being used, and based on what I've read in doc/extension.rdoc, I'm not entirely sure if it's correct for curry to use to_int. So just reporting this for now before submitting a PR. -- https://bugs.ruby-lang.org/

3 3

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

09 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/

2 2

[ruby-core:126860] [Ruby Bug#22384] Regexp compile error in the 2nd+ branch of a top-level alternation leaks the parse tree (regression from #13332, Ruby 4.0)
by sethuarun (Sethupathi Arunachalam) 09 Oct '26

09 Oct '26

Issue #22384 has been reported by sethuarun (Sethupathi Arunachalam). ---------------------------------------- Bug #22384: Regexp compile error in the 2nd+ branch of a top-level alternation leaks the parse tree (regression from #13332, Ruby 4.0) https://bugs.ruby-lang.org/issues/22384 * Author: sethuarun (Sethupathi Arunachalam) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- **Affects:** ruby 4.0.6 and 4.0.7 (official docker images and a jemalloc-linked build), master (commit still present). **Not affected:** 3.4.6. **Repro (plain Ruby, no extensions):** ```ruby def rss_kb = File.read('/proc/self/status')[/VmRSS:\s+(\d+)/, 1].to_i GC.start; b = rss_kb 500_000.times { Regexp.new("a|b(c") rescue nil } # RegexpError in the 2nd branch GC.start; puts "#{rss_kb - b} KB" # 4.0.6/4.0.7: ~65500 KB (134 B per compile); 3.4.6: 0 500_000.times { Regexp.new("b(c") rescue nil } # same error, no alternation: 0 KB on both ``` Also leaks: "a|b|c(d" (3rd branch), "a|b)c(d". Does not leak: nested "(a|b(c)". **Why it matters:** `Regexp#to_s` (rb_reg_str_with_term, re.c) re-runs onig_new on the inner pattern of any regexp whose source starts with "(?flags:" and ends with ")" to decide whether the prefix can be dropped. For every regexp shaped `/(?:a|b)c(d)/` that inner pattern is "a|b)c(d", which hits this leak. Rails calls Regexp#to_s on every Regexp in config.filter_parameters for every request (ActiveSupport::ParameterFilter compile_filters!, one ParameterFilter per request), and Rails precompiles filter_parameters into exactly that shape, so a Rails 7.1+/8.x app with a Regexp filter leaks ~128 B per request per process on Ruby 4.0. Observed on production: +3.4 MB/h per puma worker, 145 MB per worker after 40 h (jemalloc profile stacks: rb_reg_str_with_term → onig_new → onig_parse_make_tree → parse_subexp → parse_branch → parse_exp). **Cause:** commit 35000ac2ed "Prevent double free for too big repetition quantifiers (#13332)", regparse.c parse_subexp(). Before it, the alternation list was assigned to `*top` immediately and the loop's error paths called `onig_node_free(node)`. After it, the list lives in the local `topnode` and both error paths call `onig_node_free(topnode)` only. That is right for the `fetch_token` failure (`node` was already linked into topnode by the previous iteration), but wrong for the `parse_branch` failure: parse_branch returns the partially built branch in `*top` (see its `*top = node_new_list(node, NULL)` before the loop) and that node is not yet linked into topnode, so it is never freed. **Fix:** ```diff r = parse_branch(&node, tok, term, src, end, env); if (r < 0) { + onig_node_free(node); onig_node_free(topnode); return r; } ``` (parse_branch's own error path frees only the element that failed and leaves the list in *top, as it did before #13332; the top-level `if (r < 0) { onig_node_free(node); return r; }` a few lines above already does the same for the first branch.) -- 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) 09 Oct '26

09 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/

2 1

[ruby-core:126828] [Ruby Bug#22342] IO#gets can ignore the limit argument in some edge cases
by rhenium (Kazuki Yamaguchi) 09 Oct '26

09 Oct '26

Issue #22342 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22342: IO#gets can ignore the limit argument in some edge cases https://bugs.ruby-lang.org/issues/22342 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `io.gets(rs, limit)` ignores the `limit` value and reads until `rs` is found or EOF, if the `limit`-th byte of the stream matches `rs`'s last byte and: 1. The potential start of the record separator, the `limit-rs.bytesize`-th byte of the stream is not at a character boundary ```ruby str = "\x83\\xxx".force_encoding("Windows-31J") # "ソxxx".encode("Windows-31J") IO.pipe("Windows-31J"){|r,w|w.write(str); w.close_write; p r.gets("\\", 2); p r.read} # Expected: "\x{835C}" "xxx" # Actual: "\x{835C}xxx" "" ``` 2. Or, `limit < rs.bytesize` ```ruby IO.pipe{|r,w|w.write("a:bc"); w.close_write; p r.gets(":::", 2); p r.read} # Expected: "a:" "bc" # Actual: "a:bc" "" ``` This behavior appears to date back to Ruby 1.9.x. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126848] [Ruby Bug#22380] Ruby::Box: a GC while copying a class into a box crashes
by hsbt (Hiroshi SHIBATA) 09 Oct '26

09 Oct '26

Issue #22380 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22380: Ruby::Box: a GC while copying a class into a box crashes https://bugs.ruby-lang.org/issues/22380 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 4.0.7 (2026-09-22 revision 9aea6bb2f1) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- This is a backport request for the following crash: ``` $ RUBY_BOX=1 ruby --disable-gems -W:no-experimental -e 'GC.stress = true; module Enumerable; def m; end; end' -e:1: [BUG] try to mark T_NONE object (obj: 0x00000001042efe28 T_NONE/, parent: 0x000000010416dc08 T_MODULE/Module Enumerable) ``` Fixed on master by 44fff96b0bc and 18b6bfdb67e (https://github.com/ruby/ruby/pull/18842) Ruby 4.0.7 still crashes. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126824] [Ruby Bug#22339] Ruby::Box: crash / hang at VM shutdown with RUBY_FREE_AT_EXIT=1
by Eregon (Benoit Daloze) 09 Oct '26

09 Oct '26

Issue #22339 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22339: Ruby::Box: crash / hang at VM shutdown with RUBY_FREE_AT_EXIT=1 https://bugs.ruby-lang.org/issues/22339 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-21T14:42:24Z master 41e04ff507) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- ## Summary With `RUBY_BOX=1` and `RUBY_FREE_AT_EXIT=1`, Ruby crashes or hangs while freeing boxes at VM shutdown. No user box needs to be created: the built-in boxes are enough. `box_entry_free()` walks `box->classext_cow_classes` at shutdown, but the objects in that table have already been freed by the shutdown sweep, so `free_classext_for_box()` sees a type that is no longer `T_CLASS`/`T_MODULE`/`T_ICLASS` and calls `rb_bug()`. Under ASAN the same teardown is caught one step earlier, as an iclass classext freed twice. ## Reproduction ```console $ RUBY_BOX=1 RUBY_FREE_AT_EXIT=1 ruby -e '' ``` Either environment variable alone is fine; only the combination fails. ## Observed behaviour `ruby 4.1.0dev (2026-09-21T14:42:24Z master 41e04ff507) +PRISM [arm64-darwin25]` hangs, spinning at 99% CPU. `sample(1)` of the main thread: ``` rb_ec_cleanup rb_objspace_call_finalizer rb_gc_obj_free box_entry_free (box.c, st_foreach over classext_cow_classes) st_general_foreach free_classext_for_box rb_bug ("Invalid type of object in classext_cow_classes: %s") rb_bug_without_die_internal rb_source_location_cstr _sigtramp <- SIGSEGV while printing the bug report sigsegv rb_bug_for_fatal_signal rb_source_location_cstr rb_iseq_path <- loops here forever ``` `ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [aarch64-linux]` (docker `ruby:4.0.7-slim-trixie`) dies with SIGSEGV (exit 139, core dumped) instead of hanging. The offending branch is in `free_classext_for_box()`: ```c if (RB_TYPE_P(obj, T_CLASS) || RB_TYPE_P(obj, T_MODULE)) { ... } else if (RB_TYPE_P(obj, T_ICLASS)) { ... } else { rb_bug("Invalid type of object in classext_cow_classes: %s", rb_type_str(BUILTIN_TYPE(obj))); } ``` ## ASAN evidence A Linux ASAN build of master reports a use-after-free in the same shutdown teardown, where the same `id_table` is freed twice through the identical call path: ``` ERROR: AddressSanitizer: heap-use-after-free, READ of size 8 #0 rb_id_table_free id_table.c:112:16 #1 rb_iclass_classext_free class.c:128:9 #2 rb_class_classext_foreach class.c:460:5 #3 rb_gc_obj_free gc.c:1402:9 #4 rb_gc_impl_shutdown_call_finalizer gc/default/default.c:3087:25 #5 rb_objspace_call_finalizer gc.c:1739:5 #6 rb_ec_finalize eval.c:177:5 #7 rb_ec_cleanup eval.c:268:5 freed by thread T0 here: #0 free #1 rb_gc_impl_free gc/default/default.c:8285:9 #2 rb_iclass_classext_free class.c:128:9 #3 rb_class_classext_foreach class.c:460:5 #4 rb_gc_obj_free gc.c:1402:9 #5 rb_gc_impl_shutdown_call_finalizer gc/default/default.c:3087:25 #6 rb_objspace_call_finalizer gc.c:1739:5 ``` That build additionally had a user box created before exit; the `rb_bug` reproduction above does not need one. ## Affected versions Same one-liner on each build: | build | result | | --- | --- | | master `41e04ff507`, arm64-darwin25 | hang (99% CPU) | | 4.0.7, 4.0.6, 4.0.3 (ruby-build), arm64-darwin25 | hang (99% CPU) | | 4.0.7 linux (`ruby:4.0.7-slim-trixie`, `ruby:4.0.7-slim-bookworm`) | SIGSEGV | | 4.0.6 linux (`ruby:4.0.6-slim-trixie`) | SIGSEGV | | 4.0.5, 4.0.3, 4.0.2, 4.0.1 linux (`ruby:4.0.x-slim`, `-slim-trixie`) | exits 0 | The base image makes no difference (bookworm and trixie behave the same), so this is the Ruby build rather than the distribution. Since the underlying defect is a use-after-free, the rows that exit 0 are presumably latent rather than unaffected: whether the freed object still reads back as a class depends on allocator reuse. ## Possibly a separate issue Once `rb_bug()` is reached at this point in shutdown, the bug reporter itself crashes in `rb_source_location_cstr()`, and the fatal signal handler re-enters the same function, so the process never terminates. A `rb_bug()` this late should still be able to abort. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126779] [Ruby Bug#22335] Stack corruption with >31 keyword args and refined Integer#==
by eapache_opslevel (Evan Huus) 09 Oct '26

09 Oct '26

Issue #22335 has been reported by eapache_opslevel (Evan Huus). ---------------------------------------- Bug #22335: Stack corruption with >31 keyword args and refined Integer#== https://bugs.ruby-lang.org/issues/22335 * Author: eapache_opslevel (Evan Huus) * Status: Open * ruby -v: 4.0.7 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is a messy one that originally surfaced as a flaky test in our Rails app, and required a lot of AI-assisted debugging to track down. This bug appears in the latest 4.0.7, though all of the original investigation was done against 3.3.11. If you have: - a method that takes only keyword args - has >31 keyword args - has a call-time-evaluated default value (e.g. `{}`) at argument index >31 - running in a Ruby process that has refined `Integer#==` at any point Then you get inconsistent stack corruption depending on your process's hash salt. The mechanism is nasty: - In a method with only keyword args, `vm_call_iseq_setup_kwparm_kwarg()` call `args_setup_kw_parameters()` with `klocals = argv + kw_param->bits_start - kw_param->num`, i.e. **above `cfp->sp`**, without first extending `cfp->sp` over those locals - `args_setup_kw_parameters()` uses a full hash, keyed by integer, for arguments beyond index 31 - When `args_setup_kw_parameters()` sets a key in that hash, and that key collides with another (not uncommon for a tiny hash, but still salt-dependent), it triggers an integer comparison - The refinement on `Integer#==` prevents that comparison from taking the fast path and turns it into a real C frame - Which gets pushed onto the stack, when the stack pointer hasn't been extended - Thus overwriting the other args and producing garbage The net effect is that the called method sees garbage values for the overwritten arguments. I've attached a reproducing script, which is unfortunately complex, as it needs to do some work to intentionally hit the correct hash collision depending on the process's salt. A simpler static version doesn't reproduce reliably enough to be useful. Even this version will occasionally get a hash salt with no collisions and fail to reproduce, though that seems pretty rare on my machine. ---Files-------------------------------- repro.rb (1.51 KB) -- https://bugs.ruby-lang.org/

4 4