ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-core

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-core@ml.ruby-lang.org

April 2026

  • 1 participants
  • 132 discussions
[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
0 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
0 0
  • ← Newer
  • 1
  • ...
  • 11
  • 12
  • 13
  • 14
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.