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

[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

[ruby-core:126743] [Ruby Bug#22325] out of bounds read in array
by danielchong (Daniel Chong) 16 Sep '26

16 Sep '26

Issue #22325 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22325: out of bounds read in array https://bugs.ruby-lang.org/issues/22325 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi, an OOB read seems possible in array ``` 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 seq = Range.new(bad.new(2900), bad.new(2950)).step(2) ``` asan output (truncated): ``` ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 8 ... #0 ary_make_partial_step array.c:1303 #1 rb_ary_aref1 array.c:1947 #2 vm_opt_aref vm_insnhelper.c:7224 SUMMARY: AddressSanitizer: heap-buffer-overflow array.c:1303:9 in ary_make_partial_step ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126569] [Ruby Bug#22291] Instance variables should be forbidden on Ractor-shareable objects
by jhawthorn (John Hawthorn) 16 Sep '26

16 Sep '26

Issue #22291 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22291: Instance variables should be forbidden on Ractor-shareable objects https://bugs.ruby-lang.org/issues/22291 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Usually Ractor-shareable objects are frozen, but we have a number of objects which are shareable even though they aren't frozen (and likely will have more in the future from C extensions). * Classes/Modules (ignored in this issue, they have special ivar handling) * `Ractor` * `Ractor::Port` * Isolated procs/lambdas from `Ractor.shareable_proc` * `ENV` These are set shareable without the usual checks that all referenced objects are also shareable. This causes a potential issue, because these objects could have unshareable instance variables, breaking the Ractor invariant (potentially causing race conditions and segmentation faults). Currently, we attempt to avoid this by having a check on ivars read that forbids reading these from a non-main Ractor ``` R = Ractor.new {} R.instance_variable_set(:@iv, +"mutable") Ractor.new { R.instance_variable_get(:@iv) }.value #=> Ractor::IsolationError: can not access instance variables of shareable objects from non-main Ractors ``` This is detected by checking on ivar read for objects which are shareable but **not** frozen. However this isn't sound because most of these unshareable objects can be frozen, turning the check off. ```ruby R = Ractor.new {} R.instance_variable_set(:@iv, +"mutable") R.freeze Ractor.new { R.instance_variable_get(:@iv) }.value # => no error, created Ractor got access to an object it shouldn't ``` (weird quirk: `ENV#freeze` raises, but you can `Kernel.instance_method(:freeze).bind_call(ENV)` so it's still an issue) I propose that we fix this by forbidding instance variable writes to objects which are frozen. This removes the need to check on read and maintains the Ractor invariant. ``` R = Ractor.new {} R.instance_variable_set(:@iv, 123) #=> Ractor::IsolationError: can not set instance variables of shareable Ractor objects Ractor.new { R.instance_variable_get(:@foo) # => always nil, because ivars are forbidden } ``` These objects behave essentially as though they're frozen, but only the IVs are frozen. This is an important issue to solve both for correctness, and because I want us to decide the semantics so that they can be implemented in ZJIT. Currently ZJIT won't compile ivar reads on multi-ractor mode because of this issue. (I will link a patch implementing this shortly) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:126742] [Ruby Bug#22324] Pure attributes allow Clang to remove observable C API effects
by yqtian (Yongqiang Tian) 16 Sep '26

16 Sep '26

Issue #22324 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22324: Pure attributes allow Clang to remove observable C API effects https://bugs.ruby-lang.org/issues/22324 * 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 ---------------------------------------- Several public C APIs are marked `RBIMPL_ATTR_PURE()` even though their documented behavior includes observable effects. Clang can consequently remove calls when an extension discards the return value. I reproduced three cases against current Ruby at e60ce574f0: 1. `rb_intern_const()` creates and permanently registers a symbol. When the return value is discarded, Clang removes the call and the symbol does not appear in `Symbol.all_symbols`. 2. `rb_class_inherited_p()` can raise the documented `TypeError`. When the return value is discarded, Clang removes the call and execution continues. 3. `rb_class_superclass()` can raise `TypeError` for an uninitialized class. That discarded call is also removed. The relevant extension functions are: ```c static VALUE probe_intern_discard(VALUE self, VALUE name) { rb_intern_const(StringValueCStr(name)); return Qnil; } static VALUE probe_inherited_discard(VALUE self) { rb_class_inherited_p(rb_cObject, Qnil); return ID2SYM(rb_intern("continued")); } static VALUE probe_superclass_discard(VALUE self) { VALUE uninitialized_class = rb_obj_alloc(rb_cClass); rb_class_superclass(uninitialized_class); return ID2SYM(rb_intern("continued")); } ``` The test uses a fresh generated symbol name and checks `Symbol.all_symbols` before and after the first call. It also catches `TypeError` around the two class calls. With the current headers and Clang 18, I observed: ```text intern_before=false intern_after=false expected_after=true inherited_discard=continued expected=type_error superclass_discard=continued expected=type_error ``` These removals occur even in the tested `-O0` extension build because the header explicitly tells the compiler that the calls are pure. A possible fix is to remove `RBIMPL_ATTR_PURE()` from: ```text rb_intern_const() rb_class_inherited_p() rb_class_superclass() ``` I did not remove the separate `noalias` annotation from `rb_intern_const()`, because it is not needed to reproduce this problem. After removing only the three `pure` attributes, the same extension reports: ```text intern_before=false intern_after=true expected_after=true inherited_discard=type_error expected=type_error superclass_discard=type_error expected=type_error ``` The isolated change leaves the independent typed-data null probe unchanged, and the complete patched Ruby tree passes `make test`. Should these symbol-registration and documented exception effects be preserved when callers discard the return values? If so, is removing `pure` from these three declarations the preferred correction, or is there a narrower contract Ruby would prefer for any of them? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126729] [Ruby Bug#22317] Also update lib/rubygems/vendor/resolv/lib/resolv.rb for CVE issue??
by mtasaka (Mamoru TASAKA) 16 Sep '26

16 Sep '26

Issue #22317 has been reported by mtasaka (Mamoru TASAKA). ---------------------------------------- Bug #22317: Also update lib/rubygems/vendor/resolv/lib/resolv.rb for CVE issue?? https://bugs.ruby-lang.org/issues/22317 * Author: mtasaka (Mamoru TASAKA) * Status: Open * ruby -v: 4.0.7 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Recently two CVE security issues are reported against resolv gem, and looks like fixed resolv 0.7.2 was pushed into ruby_4_0 branch: https://github.com/ruby/ruby/commit/2da9a6ef3f423fb85acfd5c41150bb22cdeb14ef which updates lib/resolv.rb in ruby tree, which is finally included in released ruby 4.0.7 tarball. However, there is another "resolv.rb" under lib/rubygems/vendor/resolv/lib/ in ruby 4.0.7 "tarball" and it says the version is still 0.7.0, so looks like this is still affected by CVE issue. https://github.com/ruby/ruby/blob/v4.0.7/lib/rubygems/vendor/resolv/lib/res… So propably the above file also needs updating?? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126735] [Ruby Misc#22320] Build fails with SIGSEGV in `miniruby` during `builtin_binary` on macOS 26 (Tahoe): `pipe2` declared by SDK but absent from libSystem at runtime
by mreiche＠adobe.com (Michael Reiche) 16 Sep '26

16 Sep '26

Issue #22320 has been reported by mreiche(a)adobe.com (Michael Reiche). ---------------------------------------- Misc #22320: Build fails with SIGSEGV in `miniruby` during `builtin_binary` on macOS 26 (Tahoe): `pipe2` declared by SDK but absent from libSystem at runtime https://bugs.ruby-lang.org/issues/22320 * Author: mreiche(a)adobe.com (Michael Reiche) * Status: Open ---------------------------------------- **Environment** - macOS 26.6.2 (Tahoe), Apple Silicon (arm64) - Apple clang 21.0.0 (clang-2100.3.34.2), target `arm64-apple-darwin25.6.0` - Ruby 3.4.10 (also reproduced on 4.0.7), built via ruby-build 20260915 / rbenv - Also reproduces with a plain `./configure && make` from the release tarball **Summary** On macOS 26, `make` dies with `Segmentation fault: 11` at the step that runs the freshly-linked `miniruby` to generate `builtin_binary.inc` (`builtin_binary.rbbin`). Every Ruby version fails identically, because `miniruby` segfaults *on launch* during interpreter init. ``` compiling enc/trans/newline.c linking miniruby make: *** [builtin_binary.inc] Segmentation fault: 11 ``` **Root cause** macOS 26's SDK now **declares `pipe2()`** in its headers, so Ruby's `configure` sets `HAVE_PIPE2` and `rb_cloexec_pipe()` compiles a call to `pipe2`. However, **libSystem does not actually provide the symbol at runtime**. The weak-imported `_pipe2` binds to NULL, and the call during timer-thread setup jumps to address 0. Crash report (`~/Library/Logs/DiagnosticReports/miniruby-*.ips`): ``` Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0000000000000000 Faulting thread frames: 0x0 ← call through NULL function pointer miniruby rb_cloexec_pipe miniruby setup_communication_pipe_internal miniruby rb_thread_create_timer_thread miniruby Init_Thread miniruby rb_call_inits miniruby ruby_setup / ruby_init miniruby main dyld start ``` Confirmation that `pipe2` is declared but not present at runtime: ``` $ cat > /tmp/pipe2test.c <<'EOF' #include <stdio.h> extern int pipe2(int[2], int); int main(void){ printf("%p\n", (void*)pipe2); return 0; } EOF $ clang -o /tmp/pipe2test /tmp/pipe2test.c && /tmp/pipe2test dyld[]: Symbol not found: _pipe2 Expected in: /usr/lib/libSystem.B.dylib ``` **Steps to reproduce** 1. On macOS 26 (Apple Silicon), build Ruby 3.4.x from source (`./configure && make`). 2. `make` segfaults at `builtin_binary.inc` while executing `miniruby`. **Expected** `configure` should not enable `HAVE_PIPE2` when the symbol is declared but unavailable at runtime, or `rb_cloexec_pipe` should guard the call (e.g. `__builtin_available` / weak-symbol NULL check) and fall back to `pipe()` + `FD_CLOEXEC`. **Actual** `HAVE_PIPE2` is enabled based solely on the declaration; the resulting binary calls a NULL symbol and crashes. **Workaround** ``` ac_cv_func_pipe2=no ./configure ... # or, with rbenv: RUBY_CONFIGURE_OPTS="ac_cv_func_pipe2=no" rbenv install 3.4.10 ``` **Suggested fix** Make the `pipe2` detection on Darwin a *link-and-availability* test rather than a declaration check, or wrap the call site with an availability guard so it degrades to the `pipe()` fallback when `&pipe2 == NULL`. (macOS historically lacked `pipe2`; the macOS 26 SDK appears to declare it ahead of libSystem actually providing it.) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126449] [Ruby Bug#22254] [Prism] Clang UBSan reports NULL/0 memcpy while serializing empty strings
by yqtian (Yongqiang Tian) 15 Sep '26

15 Sep '26

Issue #22254 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22254: [Prism] Clang UBSan reports NULL/0 memcpy while serializing empty strings https://bugs.ruby-lang.org/issues/22254 * Author: yqtian (Yongqiang Tian) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-20T02:56:29Z master ed0b427b4b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I found a public `Prism.dump` path that passes a null source and zero length to `memcpy` in Prism's buffer helper. Clang's `nonnull-attribute` sanitizer reports the call because the effective glibc declaration marks the first two `memcpy` arguments as nonnull. I have not observed a crash, output corruption, or an ordinary non-sanitized failure. I am reporting this as a C correctness/toolchain-contract issue, not a security issue. #### Environment ```text x86-64 Ubuntu Clang 18.1.3 Ruby revision: ed0b427b4ba3c776c763d2673070e88372b2096a Relevant sanitizer: -fsanitize=nonnull-attribute Optimization: -O1 ``` I also checked Ruby HEAD `4012a96bf084d035bf582d58c7dafb31f4762ac6` and the corresponding Prism HEAD `3ea210b30108432b8b75b979872f4fa3c23acb7b`; the source site was unchanged. #### Reproduction From a Ruby checkout, create an out-of-tree build with the same flags used in the validation: ```sh ./autogen.sh mkdir build-ubsan cd build-ubsan ../configure \ CC=clang-18 \ CXX=clang++-18 \ CFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" \ CXXFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" \ LDFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all" \ optflags="-O1" \ debugflags="-g" \ --disable-install-doc \ --with-baseruby=/usr/bin/ruby make -j4 UBSAN_OPTIONS=print_stacktrace=0:halt_on_error=0:report_error_type=1 \ ruby ../tool/runruby.rb -- -rprism -e 'Prism.dump("//")' ``` Clang reports: ```text prism/buffer.c:86:40: runtime error: null pointer passed as argument 2, which is declared to never be null ``` Other reproducing inputs include `%r{}`, `//im`, and an empty quoted symbol. Nonempty regexps and symbols, an ordinary empty string, and `%q[]` were clean controls. #### Cause Some Prism node fields use a null-backed empty string representation. `pm_serialize_string` passes the source and zero length through `pm_buffer_append_bytes` to: ```c static PRISM_INLINE void pm_buffer_append(pm_buffer_t *buffer, const void *source, size_t length) { size_t cursor = buffer->length; if (pm_buffer_append_length(buffer, length)) { memcpy(buffer->value + cursor, source, length); } } ``` A sink-side repair is: ```c if (pm_buffer_append_length(buffer, length)) { if (length > 0) { memcpy(buffer->value + cursor, source, length); } } ``` Another possibility is to skip `pm_buffer_append_bytes` when `length == 0` in the serialization template, preserving a stricter buffer-helper invariant. Should the buffer append helpers define a zero-length append as a no-op even when the source is null, or should the serialization caller filter null-backed empty strings? #### Validation I built unmodified and guarded trees with identical Docker/compiler/configure flags. The reproducing `Prism.dump` inputs report in the unmodified build and are clean in both recover and `halt_on_error=1` modes after adding the buffer guard. The unmodified and guarded builds produced byte-identical output for `Prism.dump("//")`: ```text SHA-256 eff5e01617aa527a49aa3b900589b163e4e396807ba252e8440c8a8fbfe047a5 ``` The same native test set passed in both builds, including 1,003 Prism dump tests with 403,474 assertions, plus Prism freeze/parse and Ruby eval/proc/syntax tests. The guarded build produced no `buffer.c` report in this test set. I would be happy to prepare a patch after confirming whether the preferred repair belongs in the common buffer helper or the serialization template. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126448] [Ruby Bug#22253] Clang UBSan reports NULL/0 memcpy for eval scope locals
by yqtian (Yongqiang Tian) 15 Sep '26

15 Sep '26

Issue #22253 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22253: Clang UBSan reports NULL/0 memcpy for eval scope locals https://bugs.ruby-lang.org/issues/22253 * Author: yqtian (Yongqiang Tian) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-20T02:56:29Z master ed0b427b4b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I found a normal Ruby eval path that passes a null source and zero length to `memcpy` in Prism. Clang's `nonnull-attribute` sanitizer reports the call because the effective glibc declaration marks the first two `memcpy` arguments as nonnull. I have not observed a crash, output corruption, or an ordinary non-sanitized failure. I am reporting this as a C correctness/toolchain-contract issue, not a security issue. #### Environment ```text x86-64 Ubuntu Clang 18.1.3 Ruby revision: ed0b427b4ba3c776c763d2673070e88372b2096a Relevant sanitizer: -fsanitize=nonnull-attribute Optimization: -O1 ``` I also checked Ruby HEAD `4012a96bf084d035bf582d58c7dafb31f4762ac6` and the corresponding Prism HEAD `3ea210b30108432b8b75b979872f4fa3c23acb7b`; the source site was unchanged. #### Reproduction I configured Ruby with Clang and the following flags: ```sh CFLAGS="-fsanitize=nonnull-attribute -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" LDFLAGS="-fsanitize=nonnull-attribute -fsanitize-recover=all" ``` Run with the instrumented Ruby: ```sh UBSAN_OPTIONS=print_stacktrace=0:halt_on_error=0:report_error_type=1 \ ./ruby -e '1.times { _1; eval("") }' ``` Clang reports: ```text prism/prism.c:23015:35: runtime error: null pointer passed as argument 2, which is declared to never be null ``` The same report occurs with `_1` through `_9`, `binding.eval`, `local_variables`, and an implicit-`it` variant. #### Cause CRuby constructs the eval scope-local array. A retained slot can have `source == NULL` and `length == 0`. `pm_parser_init` then executes: ```c const uint8_t *source = pm_string_source(local); size_t length = pm_string_length(local); uint8_t *allocated = (uint8_t *) pm_arena_alloc(&parser->metadata_arena, length, 1); memcpy(allocated, source, length); ``` A consumer-side guard removes the report: ```c if (length > 0) { memcpy(allocated, source, length); } ``` However, this crosses the CRuby/Prism integration boundary. An alternative is for CRuby to compact or initialize every retained eval-scope local before passing it to Prism. Is `{ source = NULL, length = 0 }` intended to be accepted as an empty `pm_string_t`/scope-local representation here? If so, `pm_parser_init` could handle it as a zero-length value. Otherwise, CRuby may need to guarantee a nonnull source for every retained scope-local entry. #### Validation I built unmodified and guarded trees with identical Docker/compiler/configure flags. The reproducer reports in the unmodified build and is clean in both recover and `halt_on_error=1` modes after adding the guard. The same native test set passed in both builds, including 2,065 `btest` cases, 39 eval tests with 537 assertions, and the proc and syntax tests that exercise this site. The guarded build preserved the behavior of the tested eval paths. I would be happy to prepare a patch after confirming whether the preferred invariant belongs in CRuby's eval-scope producer or Prism's consumer. -- https://bugs.ruby-lang.org/

3 3