- ruby-core - ml.ruby-lang.org

[ruby-core:126760] [Ruby Bug#22330] heap uaf from string.encode()
by danielchong (Daniel Chong) 18 Sep '26

18 Sep '26

Issue #22330 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22330: heap uaf from string.encode() https://bugs.ruby-lang.org/issues/22330 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0-dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, a heap UAF seems possible in string's encode function. PoC ``` s = "あ" * 4000 s.encode("US-ASCII", fallback: proc { |c| s.replace("Z" * (16 * 1024 * 1024)) "?" }) ``` ASAN output (truncated): ``` ERROR: AddressSanitizer: heap-use-after-free ... READ of size 1 #0 transcode_restartable0 transcode.c:592:36 (*in_p) #1 transcode_restartable transcode.c:828 #2 rb_transcoding_convert transcode.c:864 #3 trans_sweep transcode.c:1191 #4 rb_trans_conv transcode.c:1281 #5 rb_econv_convert0 transcode.c:1400 #6 rb_econv_convert transcode.c:1508 #7 transcode_loop transcode.c:2417 (goto resume -> rb_econv_convert) #8 str_transcode0 transcode.c:2877 #9 str_transcode transcode.c:2907 #10 str_encode transcode.c:2973 freed by thread T0 here: #15 proc_fallback transcode.c:2340 (rb_proc_call -> user code reallocs source) #16 transcode_loop_fallback_try transcode.c:2366 #18 transcode_loop transcode.c:2433 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126763] [Ruby Bug#22331] Ruby::Box: a box's top self lacks the top-level definition methods
by hsbt (Hiroshi SHIBATA) 18 Sep '26

18 Sep '26

Issue #22331 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22331: Ruby::Box: a box's top self lacks the top-level definition methods https://bugs.ruby-lang.org/issues/22331 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 4.1.0dev (2026-09-17T00:01:17Z master 3f6143715a) [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, loading a file into a box fails on `private`, `public`, `include`, `using`, `define_method` and `ruby2_keywords`. ```ruby # toplevel.rb private def hidden; end puts "loaded" ``` ``` $ RUBY_BOX=1 ruby -W:no-experimental -e 'Ruby::Box.new.load(File.expand_path("toplevel.rb"))' toplevel.rb:1:in '<top (required)>': undefined method 'private' for #<Object:0x000000012421c180> (NoMethodError) $ RUBY_BOX=1 ruby -W:no-experimental -e 'load(File.expand_path("toplevel.rb"), true)' toplevel.rb:1:in '<top (required)>': undefined method 'private' for #<Object:0x00000001204bc180> (NoMethodError) ``` Without a box the same wrapped load only warns. Asking the loaded file what it has shows the difference: ``` $ ruby -e 'load(File.expand_path("show.rb"), true)' [:define_method, :include, :private, :public, :ruby2_keywords, :using] $ RUBY_BOX=1 ruby -W:no-experimental -e 'Ruby::Box.new.load(File.expand_path("show.rb"))' [] ``` The six methods are defined during setup on the singleton class of `rb_vm_top_self()` (`eval.c:2311`, `vm_method.c:3737`, `proc.c:5477`), before the root box exists, so all six land on the master box's top self. `box_entry_initialize()` (`box.c:170`) then gives every other box a fresh object carrying only `to_s` and `inspect`, and `load_wrapping()` (`load.c:848`) clones the current box's one. Top level still sees the master box's object, so the gap shows only from a file loaded into a box. So the question is what a box's top self should be. Three shapes I can see: - give every box a clone of the master box's top self, and let root and main share the master's object itself (https://github.com/ruby/ruby/pull/18707) - define the six methods on each box's own top self when the box is created, the way https://github.com/ruby/ruby/pull/18713 loads the prelude per box; - let every box share the master box's top self, making `main` one object process-wide. They differ in whether a singleton method added to `main` in one box is visible in another. Is there another shape you would prefer? The same identity gap also breaks four autoload specs under a box. Reproduced on master 3f6143715a and on released 4.0.7. Related to #22275 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126758] [Ruby Feature#22329] Specify --disable-gem per Ruby Box
by tagomoris (Satoshi Tagomori) 17 Sep '26

17 Sep '26

Issue #22329 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #22329: Specify --disable-gem per Ruby Box https://bugs.ruby-lang.org/issues/22329 * Author: tagomoris (Satoshi Tagomori) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * Target version: 4.1 ---------------------------------------- Currently user boxes loads gems listed in the gem_prelude.rb if those gems are enabled in the process-wide. There is just only way to disable gems in boxes: specify `--disable-gems` in the entire process. This proposes a new keyword argument on `Ruby::Box#new` to disable gems per box. This makes possible to create a simple, clean boxes if the box doesn't require RubyGems and other bundled gems. Boxes without RubyGems are still useful for loading small scripts, reducing security risks by keeping load_path clean&simple, etc. ``` # RubyGems is enabled in main Gem #=> Gem # Create a box without RubyGems box = Ruby::Box.new(disable_gems: true) box::Gem # NameError ``` The default value of `disable_gems` is `false. There may be two options to have keyword arguments: * have all of `disable_gems`, `error_highlight`, `did_you_mean`, `syntax_suggest` similar to the command line options * have only `disable_gems` to disable all of 4 gems IMO having only `disable_gems` looks enough because all of RubyGems/ErrorHightlight/DidYouMean/SyntaxSuggest bring the better developer experience. The single keyword argument `disable_gems` can explain well: "this box doesn't expect those developer-centric features". Another discussion point is how we should handle `Ruby::Box.new(disable_gems: false)` when the process-wide `--disable-gems` is specified. Options: * respect the process-wide selection and leave RubyGems an others are not loaded * try to load RubyGems and others only in the box I prefer the first option, but it's not a strong opinion. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126756] [Ruby Bug#22328] Should IO#wait_priority be deprecated and then removed?
by sampokuokkanen (Sampo Kuokkanen) 17 Sep '26

17 Sep '26

Issue #22328 has been reported by sampokuokkanen (Sampo Kuokkanen). ---------------------------------------- Bug #22328: Should IO#wait_priority be deprecated and then removed? https://bugs.ruby-lang.org/issues/22328 * Author: sampokuokkanen (Sampo Kuokkanen) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In #18655, IO#wait_readable, IO#wait_writable, IO#wait_priority, and IO#wait were moved from io/wait into core. However, in #18655 note 11, Matz wrote: > After the discussion, we will drop wait_priority, but others are accepted. https://bugs.ruby-lang.org/issues/18655#note-11 https://github.com/ruby/dev-meeting-log/blob/d16be491afb7f3c0d956a6445dcb17… IO#wait_priority is still present in core today. It does not seem to be used that much: https://github.com/search?type=code&q=.wait_priority+language%3ARuby&l=Ruby So my question is, should it be deprecated and removed? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126741] [Ruby Bug#22323] Incorrect nonnull contract changes rb_typeddata_inherited_p(NULL, NULL) behavior
by yqtian (Yongqiang Tian) 17 Sep '26

17 Sep '26

Issue #22323 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22323: Incorrect nonnull contract changes rb_typeddata_inherited_p(NULL, NULL) behavior https://bugs.ruby-lang.org/issues/22323 * Author: yqtian (Yongqiang Tian) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-16T01:40:57Z :detached: e60ce574f0) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `rb_typeddata_inherited_p()` documents that both arguments may be `NULL`, and its implementation returns true for `(NULL, NULL)`. However, both the exported declaration and the inline implementation are marked with `RBIMPL_ATTR_NONNULL(())`, which tells GCC and Clang that all pointer arguments are nonnull. This contradictory contract can change observable behavior under optimization. ## Relevant code The declaration is annotated as follows: ```c RBIMPL_ATTR_NONNULL(()) /** * Checks for the domestic relationship between the two. * * ... * * You can pass NULL to both arguments, don't know what that means though. */ int rb_typeddata_inherited_p(const rb_data_type_t *child, const rb_data_type_t *parent); ``` The inline implementation has the same annotation: ```c RBIMPL_ATTR_NONNULL(()) static inline bool rbimpl_typeddata_inherited_p_inline(const rb_data_type_t *child, const rb_data_type_t *parent) { do { if (RB_LIKELY(child == parent)) return true; } while ((child = child->parent) != NULL); return false; } #define rb_typeddata_inherited_p rbimpl_typeddata_inherited_p_inline ``` Because the equality check occurs before `child` is dereferenced, `rb_typeddata_inherited_p(NULL, NULL)` returns true according to the implementation. The relevant header is: https://github.com/ruby/ruby/blob/e60ce574f0/include/ruby/internal/core/rty… ## Reproducer I reproduced the issue with the following minimal C extension: ```c #include <ruby.h> #include <stdint.h> static VALUE typeddata_null(VALUE self, VALUE use_nonnull) { const rb_data_type_t *type = RTEST(use_nonnull) ? (const rb_data_type_t *)(uintptr_t)1 : NULL; int inherited = rb_typeddata_inherited_p(type, type); /* * Returning 2 means the compiler selected the type != NULL branch. * When use_nonnull is false, the expected result is inherited == 1. */ return INT2NUM(type != NULL ? 2 : inherited); } void Init_typeddata_null(void) { VALUE module = rb_define_module("TypeddataNull"); rb_define_singleton_method(module, "check", typeddata_null, 1); } ``` With this `extconf.rb`: ```ruby require "mkmf" create_makefile("typeddata_null") ``` I built the extension with Clang 18 at `-O0` and `-O2`, then ran: ```sh ruby -I. -r./typeddata_null -e 'p TypeddataNull.check(false)' ``` The results were: ```text Clang 18 -O0: 1 Clang 18 -O2: 2 ``` The argument to `check()` is `false`, so `type` is `NULL` at runtime. The expected result is therefore `1`: the two pointers are equal and `rb_typeddata_inherited_p(NULL, NULL)` returns true. The value `2` is not a return value from `rb_typeddata_inherited_p()`. It is a marker showing that Clang selected the later `type != NULL` branch. The `nonnull` annotation allows Clang to assume that `type` cannot be null after it has been passed to the function, even though the documented and implemented `(NULL, NULL)` case was used. Clang 14 generated the same optimized control flow. GCC and Clang also emit `-Wnonnull` diagnostics when the two null arguments are written directly. ## Possible fix If `(NULL, NULL)` is intended to remain supported, I believe the incompatible `RBIMPL_ATTR_NONNULL(())` annotations should be removed from both the exported declaration and `rbimpl_typeddata_inherited_p_inline()`. Removing only the annotation from the exported declaration is not sufficient because extension calls are redirected to the annotated inline implementation by the macro. After removing both annotations, the Clang 18 `-O2` extension reports: ```text 1 ``` The complete patched Ruby tree also passes `make test`. Could you confirm whether `(NULL, NULL)` is an intended input for this function? If it is not intended, the documentation and the explicit equality behavior may instead need to be updated. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:126537] [Ruby Bug#22276] alias in a module falls back to Object even in classes not inheriting from Object
by shugo (Shugo Maeda) 17 Sep '26

17 Sep '26

Issue #22276 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22276: alias in a module falls back to Object even in classes not inheriting from Object https://bugs.ruby-lang.org/issues/22276 * Author: shugo (Shugo Maeda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-28T07:43:16Z master 69b49ac7ae) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When `alias` (or `alias_method`) is used in a module and the method is not found in the module, `alias` searches the method from `Object`. So a module can alias a method of `Kernel` or `Object`, and the alias works even if the module is later included in a class that does not have `Object` and `Kernel` as ancestors: ```ruby module M alias foo puts public :foo end class X < BasicObject include ::M end X.new.foo("hello") #=> hello ``` `X` does not include `Kernel`, but `X.new.foo` calls `Kernel#puts`. This fallback comes from Ruby 1.8, where `Object` was the root class, so every class that includes a module always had `Object` and `Kernel` as ancestors. Since Ruby 1.9 introduced `BasicObject`, this is no longer true, but the fallback is unchanged. As discussed in #22273, a module should be able to alias only its own methods and its ancestors' methods, and `Object` is not an ancestor of a module. This behavior is intentional in the current implementation. There are tests for it (`test_alias_in_module` in test/ruby/test_alias.rb for #9663, and "accesses a method defined on Object from Kernel" in spec/ruby/core/module/alias_method_spec.rb), and the documentation of `Module#alias_method` has an example `module Mod; alias_method :orig_exit, :exit; end`. So code like `module M; alias orig_to_s to_s; end` exists, and simply raising `NameError` will break it. Possible fixes: 1. Remove the fallback and raise `NameError`. This breaks existing code. 2. Do not resolve the method at alias time. Instead, resolve it at call time from the ancestors of the receiver's class, like ZSUPER methods. Existing code that includes the module in a subclass of `Object` keeps working, and `X.new.foo` above raises `NoMethodError`. 3. Keep the current behavior and document it. I think 2 is the best choice for compatibility. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123881] [Ruby Bug#21703] RUBY_CRASH_REPORT does not work when shelling out in some cases
by peterzhu2118 (Peter Zhu) 17 Sep '26

17 Sep '26

Issue #21703 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21703: RUBY_CRASH_REPORT does not work when shelling out in some cases https://bugs.ruby-lang.org/issues/21703 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/15292 RUBY_CRASH_REPORT does not work in some cases when shelling out on Linux. For example, given the following shell script dump.sh: ```sh #!/usr/bin/env bash cat > /tmp/crash ``` And we see it fails like this: ``` $ RUBY_CRASH_REPORT="|dump.sh" ruby -rfiddle -e "Fiddle::Pointer.new(1, 10)[0]" cat: -: Resource temporarily unavailable ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126678] [Ruby Bug#22311] Build crashes on macOS 26 with the macOS 27 SDK because pipe2() and dup3() are unavailable
by himura467 (Akito Shitara) 17 Sep '26

17 Sep '26

Issue #22311 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22311: Build crashes on macOS 26 with the macOS 27 SDK because pipe2() and dup3() are unavailable https://bugs.ruby-lang.org/issues/22311 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Environment - macOS 26.6.2 - Command Line Tools with MacOSX27.0.sdk (default `MacOSX.sdk`) - Apple clang version 21.0.0 (clang-2100.3.34.2) ## Steps to reproduce ./autogen.sh mkdir build && cd build ../configure make ## Result The build warns about `dup3` and `pipe2`, and then miniruby crashes: ../io.c:389:19: warning: 'dup3' is only available on macOS 27.0 or newer [-Wunguarded-availability-new] ../io.c:432:18: warning: 'pipe2' is only available on macOS 27.0 or newer [-Wunguarded-availability-new] ../io.c:8141:18: warning: 'pipe2' is only available on macOS 27.0 or newer [-Wunguarded-availability-new] ... make: *** [uncommon.mk:1331: builtin_binary.rbbin] Segmentation fault: 11 ## Cause The macOS 27 SDK declares `dup3()` and `pipe2()` as available since macOS 27.0. `AC_CHECK_FUNCS` links them without including headers, so configure defines `HAVE_DUP3` and `HAVE_PIPE2`. In io.c, they are weakly linked through the header and are NULL at runtime on macOS 26. $ nm -m miniruby | grep -E '_(pipe2|dup3) ' (undefined) weak external _dup3 (from libSystem) (undefined) weak external _pipe2 (from libSystem) ## Notes Autoconf 2.73 makes `AC_CHECK_DECL` report "no" for such functions on macOS. https://github.com/autotools-mirror/autoconf/blob/0a51305fff8847edd3e9da9e5… -- https://bugs.ruby-lang.org/

4 5

[ruby-core:125919] [Ruby Bug#22174] Set operations (&, ^, collect!, flatten, classify, divide) do not preserve compare_by_identity
by gil.desmarais (Gil Desmarais) 17 Sep '26

17 Sep '26

Issue #22174 has been reported by gil.desmarais (Gil Desmarais). ---------------------------------------- Bug #22174: Set operations (&, ^, collect!, flatten, classify, divide) do not preserve compare_by_identity https://bugs.ruby-lang.org/issues/22174 * Author: gil.desmarais (Gil Desmarais) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Since `Set` was transitioned to a C-level core class in Ruby 4.0, several operations that allocate new sets or partition subsets (`&`, `^`, `collect!`, `flatten`, `classify`, and `divide`) lost the `compare_by_identity` behavior for the receiver set or its subsets. * For `&`, `collect!`, `flatten`, `classify`, and `divide`, the resulting sets/subsets are allocated without propagating the `compare_by_identity` flag (returning `false` for `#compare_by_identity?`). * For `^` (XOR) with a generic `Enumerable`, the returned set has the flag set (via `dup`), but it allocates a temporary set `tmp` to hold the RHS elements without propagating the `compare_by_identity` flag. This causes the RHS elements to be deduplicated incorrectly using value equality instead of identity equality. A pull request has been opened with the fix and tests: https://github.com/ruby/ruby/pull/17633 ### Reproduction ```ruby require 'set' # 1. Intersection & s1 = Set.new.compare_by_identity s2 = Set.new s1 << "a" s2 << "a" puts "Intersection preserves compare_by_identity: #{(s1 & s2).compare_by_identity?}" # Expected: true # Actual: false # 2. XOR ^ (with duplicate objects by value on RHS) s_xor = Set.new.compare_by_identity x1 = +"x" x2 = +"x" result = s_xor ^ [x1, x2] puts "XOR with Enumerable preserves identity comparison: #{result.size == 2}" # Expected: true (size should be 2, because x1 and x2 are distinct objects) # Actual: false (size is 1) # 3. collect! / map! s_collect = Set.new(["a", "b"]).compare_by_identity s_collect.collect! { |x| x } puts "collect! preserves compare_by_identity: #{s_collect.compare_by_identity?}" # Expected: true # Actual: false # 4. flatten s_flat = Set.new([Set.new([1])]).compare_by_identity puts "flatten preserves compare_by_identity: #{s_flat.flatten.compare_by_identity?}" # Expected: true # Actual: false # 5. classify s_classify = Set.new(["a", "b"]).compare_by_identity classified = s_classify.classify { |x| x } puts "classify subsets preserve compare_by_identity: #{classified.values.all?(&:compare_by_identity?)}" # Expected: true # Actual: false # 6. divide s_divide = Set.new(["a", "b"]).compare_by_identity divided = s_divide.divide { |x| x } puts "divide subsets preserve compare_by_identity: #{divided.all?(&:compare_by_identity?)}" # Expected: true # Actual: false -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126747] [Ruby Bug#22327] RubyVM::ZJIT.reset_stats! aborts the process (Rust panic) when ZJIT is not enabled
by znz (Kazuhiro NISHIYAMA) 17 Sep '26

17 Sep '26

Issue #22327 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #22327: RubyVM::ZJIT.reset_stats! aborts the process (Rust panic) when ZJIT is not enabled https://bugs.ruby-lang.org/issues/22327 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Assignee: jit * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- `RubyVM::ZJIT.reset_stats!` aborts the whole process with a Rust panic when it is called while ZJIT is not enabled. The other stats methods (`stats`, `stats_string`, `stats_enabled?`) just return `nil`/`false` in the same situation, and `RubyVM::YJIT.reset_stats!` returns `nil` when YJIT is disabled, so I think `reset_stats!` should also be a no-op instead of crashing. ## Reproduction ``` $ ruby -e 'p RubyVM::ZJIT.enabled?; RubyVM::ZJIT.reset_stats!; puts "after"' false thread '<unnamed>' (1) panicked at /usr/src/ruby/zjit/src/state.rs:200:13: ZJITState::get_instance called when ZJIT is not enabled note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread '<unnamed>' (1) panicked at .../library/core/src/panicking.rs:225:5: panic in a function that cannot unwind (backtrace and bug report dump follow) Aborted (core dumped) $ echo $? 134 ``` Expected: `after` is printed and the process exits with 0 (`reset_stats!` returns `nil`, as it does when ZJIT is enabled). Reproduced with: - ruby 4.1.0dev (2026-09-15T06:59:41Z master 0c3c61ca82) +PRISM [x86_64-linux] (`ghcr.io/ruby/ruby:master`; panic at `zjit/src/state.rs:200`) - ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux] (`ghcr.io/ruby/ruby:4.0.7`; panic at `zjit/src/state.rs:168`) For comparison, these do not crash: ``` $ ruby -e 'p RubyVM::ZJIT.stats, RubyVM::ZJIT.stats_string, RubyVM::ZJIT.stats_enabled?' nil nil false $ ruby -e 'p RubyVM::YJIT.enabled?, RubyVM::YJIT.reset_stats!' false nil $ ruby --zjit -e 'p RubyVM::ZJIT.enabled?, RubyVM::ZJIT.reset_stats!' true nil ``` ## Cause `rb_zjit_reset_stats_bang` in `zjit/src/stats.rs` calls `ZJITState::get_counters()` etc. unconditionally, and `ZJITState::get_instance` panics when the state has not been initialized. `rb_zjit_stats` in the same file starts with `if !zjit_enabled_p() { return Qnil; }`; adding the same guard to `rb_zjit_reset_stats_bang` would fix this. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- https://bugs.ruby-lang.org/

1 0