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

[ruby-core:124270] [Ruby Bug#21787] `IO::Buffer` buffer overf
by nobu (Nobuyoshi Nakada) 04 Apr '26

04 Apr '26

Issue #21787 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21787: `IO::Buffer` buffer overf https://bugs.ruby-lang.org/issues/21787 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125028] [Ruby Bug#21954] NoMethodError instead of Gem::LoadError on gem activation problem in Ruby 4.0.2
by jeremyevans0 (Jeremy Evans) 04 Apr '26

04 Apr '26

Issue #21954 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21954: NoMethodError instead of Gem::LoadError on gem activation problem in Ruby 4.0.2 https://bugs.ruby-lang.org/issues/21954 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-linux] * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- I'm seeing a regression in Ruby 4.0.2 when there is a gem activation problem. Install two versions of a gem, where one version has a file the other doesn't. One example here is rack: ``` $ gem install rack --version '< 3' $ gem install rack ``` Force activation of the version that doesn't have the file, and then require the file and rescue `LoadError`: ```ruby gem 'rack', '< 3' begin require 'rack/headers' rescue LoadError end ``` In previous versions of Ruby, the `Gem::LoadError` would be correctly rescued, and you would get no output. In Ruby 4.0.2, you get a `NoMethodError` raised: ``` /usr/local/lib/ruby/4.0/rubygems.rb:196:in 'Gem.try_activate': undefined method 'name' for nil (NoMethodError) spec ||= Gem::Specification.find_by_name(spec.name) ^^^^^ from /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require' from /home/jeremy/gem-activate-problem.rb:4:in '<main>' /usr/local/lib/ruby/4.0/rubygems/specification.rb:2170:in 'Gem::Specification#check_version_conflict': can't activate rack-3.2.4, already activated rack-2.2.21 (Gem::LoadError) from /usr/local/lib/ruby/4.0/rubygems/specification.rb:1379:in 'Gem::Specification#activate' from /usr/local/lib/ruby/4.0/rubygems.rb:193:in 'Gem.try_activate' from /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require' from /home/jeremy/gem-activate-problem.rb:4:in '<main>' /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require': cannot load such file -- rack/headers (LoadError) from /home/jeremy/gem-activate-problem.rb:4:in '<main>' ``` Same behavior on both OpenBSD and Linux. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125154] [Ruby Bug#21971] Backport commit 5de4cc560864 / PR #15848
by mackuba (Kuba Suder) 04 Apr '26

04 Apr '26

Issue #21971 has been reported by mackuba (Kuba Suder). ---------------------------------------- Bug #21971: Backport commit 5de4cc560864 / PR #15848 https://bugs.ruby-lang.org/issues/21971 * Author: mackuba (Kuba Suder) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Follow-up to ticket: https://bugs.ruby-lang.org/issues/21824 There was a group of old commits merged before 4.0 which were meant to improve regexp performance in some cases. Unfortunately, they also greatly degraded regexp performance in some other cases. This was released in version 4.0.0, where I noticed it when testing the performance of the final version in my app, and reported it as 21824. Chris Hasiński has fixed this on the master branch in commit 5de4cc56086493689701e86aa0ccf6a4a4a87d75, however this wasn't released as a bugfix with Ruby 4.0.1 & 4.0.2. It would be great if this could be backported to the ruby_4_0 branch and included in the 4.0.3 bugfix release. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125183] [Ruby Bug#21980] RubyVM::AST offsets are incorrect when BOM
by kddnewton (Kevin Newton) 02 Apr '26

02 Apr '26

Issue #21980 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21980: RubyVM::AST offsets are incorrect when BOM https://bugs.ruby-lang.org/issues/21980 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When there is a BOM on a file, the offsets are incorrect for nodes. See: ``` RubyVM::AbstractSyntaxTree.parse("\xEF\xBB\xBF1").source # => "\xEF" ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125167] [Ruby Feature#21976] Add $SECONDS, $RANDOM, and other bashisms
by jhawthorn (John Hawthorn) 02 Apr '26

02 Apr '26

Issue #21976 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #21976: Add $SECONDS, $RANDOM, and other bashisms https://bugs.ruby-lang.org/issues/21976 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- Some time ago there was a lot of discussion around a script named [safe_sleep.sh](https://github.com/actions/runner/blob/af6c8e6eddef233fdef86… in the GitHub Actions runner. Like [many others](https://github.com/actions/runner/issues/2380), I immediately saw the serious problem with this script: it isn't written in Ruby! To better support this use case, and to be able to sleep safely, Ruby should support `$SECONDS` as well as other bashisms like `$RANDOM`, `$1`, etc. This would allow us to rewrite ```bash #!/bin/bash SECONDS=0 while [[ $SECONDS != $1 ]]; do : done ``` In Ruby ```ruby #!/usr/bin/env -S ruby -rbashisms $SECONDS = 0 while $SECONDS != $1.to_i ; end ``` ``` $ ruby -rbashisms -e 'echo $BASH_VERSION' 4.1.2026(4.0.1)-release (ruby) $ ./safe_sleep.rb 5 ``` For ease of evaluating this proposed feature I've have created the [`bashisms` gem](https://github.com/jhawthorn/bashisms) please give it a try! -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125161] [Ruby Bug#21974] Cannot inspect RubyVM::AST for CDECL
by kddnewton (Kevin Newton) 02 Apr '26

02 Apr '26

Issue #21974 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21974: Cannot inspect RubyVM::AST for CDECL https://bugs.ruby-lang.org/issues/21974 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` ./ruby -e 'pp RubyVM::AbstractSyntaxTree.parse("::Foo = 1")' ``` and ``` ./ruby -e 'p RubyVM::AbstractSyntaxTree.parse("::Foo = 1").children[2].children' ``` both crash -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125180] [Ruby Feature#21979] `String#unpack`/`String#unpack1` should allow negative offset
by nobu (Nobuyoshi Nakada) 02 Apr '26

02 Apr '26

Issue #21979 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21979: `String#unpack`/`String#unpack1` should allow negative offset https://bugs.ruby-lang.org/issues/21979 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- https://bugs.ruby-lang.org/issues/18254#note-14 I think `String#unpack`/`String#unpack1` should allow negative offset as well as the other methods, for example `String#slice` that is referred to in the description. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125179] [Ruby Feature#18254] Add an `offset` parameter to String#unpack and String#unpack1
by nobu (Nobuyoshi Nakada) 02 Apr '26

02 Apr '26

Issue #18254 has been updated by nobu (Nobuyoshi Nakada). I wasn't aware that negative offset is not allowed. Shouldn't `unpack`/`unpack1` also it as well as the other methods, `String#slice`, `String#[]` and so on? ---------------------------------------- Feature #18254: Add an `offset` parameter to String#unpack and String#unpack1 https://bugs.ruby-lang.org/issues/18254#change-116911 * Author: byroot (Jean Boussier) * Status: Closed ---------------------------------------- When working with binary protocols it's common to have to first unpack some kind of header or type prefix, and then based on that unpack another part of the string. For instance here's [a code snippet from Dalli, the most common Memcached client](https://github.com/petergoldstein/dalli/blob/76b79d78cda13562da17bc…: ```ruby while buf.bytesize - pos >= 24 header = buf.slice(pos, 24) (key_length, _, body_length, cas) = header.unpack(KV_HEADER) if key_length == 0 # all done! @multi_buffer = nil @position = nil @inprogress = false break elsif buf.bytesize - pos >= 24 + body_length flags = buf.slice(pos + 24, 4).unpack1("N") key = buf.slice(pos + 24 + 4, key_length) value = buf.slice(pos + 24 + 4 + key_length, body_length - key_length - 4) if body_length - key_length - 4 > 0 pos = pos + 24 + body_length begin values[key] = [deserialize(value, flags), cas] rescue DalliError end else # not enough data yet, wait for more break end end @position = pos ``` ### Proposal If `unpack` and `unpack1` had an `offset:` parameter, it would allow this kind of code to extract the fields it needs without allocating and copying as much strings, e.g.: ```ruby flags = buf.slice(pos + 24, 4).unpack1("N") ``` could be: ```ruby buf.unpack1("N", offset: pos + 24) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125176] [Ruby Bug#21978] Fix class variable cache isn't invalidated via modules
by jhawthorn (John Hawthorn) 01 Apr '26

01 Apr '26

Issue #21978 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21978: Fix class variable cache isn't invalidated via modules https://bugs.ruby-lang.org/issues/21978 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby module M; @@x = 1; end class A; end class B < A include M def self.x; @@x; end end B.x # warm cache A.class_variable_set(:@@x, 2) B.x ``` The last call to `B.x` should fail with `Should raise: class variable @@x of M is overtaken by A (RuntimeError)`, but has been returning 1 since since ruby-3.2.0-preview3. It should be solvable by by bumping the global state counter more aggressively: https://github.com/ruby/ruby/pull/16551 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125174] [Ruby Bug#21977] Ruby::Box crash with `RUBY_BOX=1` via `Binding` refinement, `UnboundMethod#bind_call`, and `Symbol#to_proc`
by singetu0096 (Rintaro Kawasugi) 01 Apr '26

01 Apr '26

Issue #21977 has been reported by singetu0096 (Rintaro Kawasugi). ---------------------------------------- Bug #21977: Ruby::Box crash with `RUBY_BOX=1` via `Binding` refinement, `UnboundMethod#bind_call`, and `Symbol#to_proc` https://bugs.ruby-lang.org/issues/21977 * Author: singetu0096 (Rintaro Kawasugi) * Status: Open * ruby -v: ruby 4.1.0dev (2026-03-24T21:47:14Z master 30dcc2a082) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I found a reproducible interpreter crash when Ruby is run with `RUBY_BOX=1`. A refinement on `Binding`, combined with `UnboundMethod#bind_call` and `Symbol#to_proc`, causes Ruby to abort with: ```text [BUG] BUG: Local ep without cme/box, flags: 66660087 ``` I reproduced this on: ```text ruby 4.1.0dev (2026-03-24T21:47:14Z master 30dcc2a082) +PRISM [x86_64-linux] ``` Follow-up validation confirmed an important discriminator: replacing `map(&:to_s)` with an explicit block such as `map { _1.to_s }` avoids the crash. The currently available evidence therefore points to a box/frame bookkeeping bug in the `Symbol#to_proc` path that reaches an explicit internal `rb_bug(...)` assertion, not to confirmed memory corruption. ## PoC ```ruby using Module.new { refine ::Binding do def eval_methods ::Kernel.instance_method(:methods).bind_call(receiver) end end } p binding.eval_methods.map(&:to_s) ``` Run: ```bash RUBY_BOX=1 ./miniruby -e ' using Module.new { refine ::Binding do def eval_methods ::Kernel.instance_method(:methods).bind_call(receiver) end end } p binding.eval_methods.map(&:to_s) ' ``` Observed result: ```text [BUG] BUG: Local ep without cme/box, flags: 66660087 ruby 4.1.0dev (2026-03-24T21:47:14Z master 30dcc2a082) +PRISM [x86_64-linux] Crashed while printing bug report ``` Important discriminator: ```ruby p binding.eval_methods.map { _1.to_s } ``` Replacing `map(&:to_s)` with an explicit block avoids the crash, which strongly suggests that the failure depends specifically on the `Symbol#to_proc` path rather than `map` in general. ## Impact The currently confirmed impact is denial of service in processes using Ruby::Box with `RUBY_BOX=1`. Confirmed claim: - reliable interpreter abort - trigger requires `RUBY_BOX=1` - trigger depends specifically on the `Symbol#to_proc` path in this setup Current non-claims: - no confirmed memory corruption - no confirmed sandbox escape - no confirmed privilege escalation - no confirmed arbitrary code execution This report should remain separate from the Ruby::Box double-free issue, because the trigger path, failure mode, and currently demonstrated impact are different. -- https://bugs.ruby-lang.org/

1 0