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

[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

[ruby-core:126226] [Ruby Bug#22224] YJIT: rb_yjit_invalidate_ep_is_bp takes the VM lock stopping Ractors on every Proc materialization; multi-Ractor throughput collapses (up to ~150x)
by yaroslavmarkin (Yaroslav Markin) 14 Sep '26

14 Sep '26

Issue #22224 has been reported by yaroslavmarkin (Yaroslav Markin). ---------------------------------------- Bug #22224: YJIT: rb_yjit_invalidate_ep_is_bp takes the VM lock stopping Ractors on every Proc materialization; multi-Ractor throughput collapses (up to ~150x) https://bugs.ruby-lang.org/issues/22224 * Author: yaroslavmarkin (Yaroslav Markin) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! Fair warning: a significant portion of this bugreport and experimentation/benchmarking was done by an agent. Sorry for the slop, but it was so much faster to benchmark and find a root issue. ## Summary With YJIT enabled, `vm_make_env_each` calls `rb_yjit_invalidate_ep_is_bp` on every Proc/lambda environment materialization. That function enters `with_vm_lock` unconditionally (the only early return covers boot, before `INVARIANTS` is initialized). In multi-Ractor mode this lock acquisition is `rb_jit_vm_lock_then_barrier`: the VM lock plus a stop-all-Ractors barrier. The result: any workload that creates Procs loses parallel scalability under Ractors, and beyond ~2 Ractors adding workers makes the whole process slower in absolute terms. In the repro below, 8 Ractors with YJIT run ~150x slower than 1 Ractor with YJIT, and ~195x slower than 8 Ractors without YJIT, on the same code. Note the invalidation itself is not the cost. After the first escape of a given iseq, its `no_ep_escape_iseqs` entry is an empty set forever (`ep_is_bp()` returns false for it, so no new blocks are ever registered), yet every subsequent materialization still pays lock + global barrier to look up the entry and iterate nothing. ## Standalone repro (no gems) ```ruby # Usage: ruby [--yjit] yjit_ractor_repro.rb [proc|calc] [n_ractors] [seconds] MODE = (ARGV[0] || "proc").to_sym N = (ARGV[1] || 1).to_i DUR = (ARGV[2] || 3).to_f def make_proc(i) x = i -> { x + 1 } # captures x: the frame env is materialized on every call end def work_proc(n) s = 0 n.times { |i| s += make_proc(i).call } s end def work_calc(n) s = 0 n.times { |i| s += (i * i) % 7 } # same shape, no Proc escapes s end def bench_loop(mode, dur) count = 0 deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + dur while Process.clock_gettime(Process::CLOCK_MONOTONIC) < deadline mode == :proc ? work_proc(1000) : work_calc(1000) count += 1000 end count end bench_loop(MODE, 0.5) # warm up: get the methods YJIT-compiled before measuring total = if N == 1 bench_loop(MODE, DUR) else N.times.map { Ractor.new(MODE, DUR) { |m, d| bench_loop(m, d) } }.sum(&:value) end puts format("mode=%s yjit=%s ractors=%d throughput=%.2fM iters/s", MODE, RubyVM::YJIT.enabled?, N, total / DUR / 1_000_000.0) ``` Results on Apple M1 Pro (10 cores), macOS, `ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25]`, 3 s per cell: | workload | ractors | interpreter (M iters/s) | --yjit (M iters/s) | |----------|---------|-------------------------|--------------------| | calc (control, no Proc) | 1 | 21.3 | 129.4 | | calc | 4 | 83.0 | 495.3 | | calc | 8 | 162.2 | **969.1** | | proc | 1 | 4.5 | 6.0 | | proc | 4 | 7.7 | **0.14** | | proc | 8 | 7.8 | **0.04** | The control shows this is not a general YJIT-vs-Ractor problem: on the Proc-free workload YJIT scales superbly (969M iters/s at 8 Ractors). Only the environment-materializing workload collapses, and only with YJIT on. ## Where the time goes Native sampling (macOS `sample`) of a loaded multi-Ractor process shows almost all threads parked in `__psynch_cvwait`, with the barrier initiated from: ``` vm_make_env_each -> rb_yjit_invalidate_ep_is_bp (yjit/src/invariants.rs) -> with_vm_lock -> rb_jit_vm_lock_then_barrier -> rb_ractor_sched_barrier_start (victims: rb_ractor_sched_barrier_join / ractor_sched_barrier_join_wait_locked) ``` In a 6 s sample of a 5-Ractor process, barrier-related frames appear ~9,000 times vs ~50 in the single-Ractor run of the same workload. Ruby-side profilers cannot see this: the wait time is attributed as diffuse "self time" across whatever frames are on top, which is presumably why it has gone unreported. Current code (`yjit/src/invariants.rs`, same on master as of 2026-08-03): ```rust pub extern "C" fn rb_yjit_invalidate_ep_is_bp(iseq: IseqPtr) { // Skip tracking EP escapes on boot. We don't need to invalidate anything during boot. if unsafe { INVARIANTS.is_none() } { return; } with_vm_lock(src_loc!(), || { let no_ep_escape_iseqs = &mut Invariants::get_instance().no_ep_escape_iseqs; match no_ep_escape_iseqs.get_mut(&iseq) { Some(blocks) => { for block in mem::take(blocks) { invalidate_block_version(&block); incr_counter!(invalidate_ep_escape); } } None => { no_ep_escape_iseqs.insert(iseq, HashSet::new()); } } }); } ``` ## Real-world impact Rails 8.1 enables YJIT by default, and a Rails request materializes many Proc environments (middleware blocks, route handling, view rendering), so any Rails app served by a multi-Ractor server hits this out of the box. Found while investigating https://github.com/yaroslav/kino/issues/6, where a stock Rails 8.1 app showed worker scaling inverting: more Ractors, less total throughput. Rails 8.1.3 health-check endpoint (`/up`, no database), `ab -c 64 -k`, kino `:ractor` mode, N workers x 1 thread, requests/sec: | workers | YJIT on (Rails default) | YJIT off | |---------|-------------------------|----------| | 1 | 6,416 | 3,964 | | 2 | 5,036 | 6,999 | | 5 | 2,800 | 13,269 | | 8 | 2,003 | 12,596 | Fully disabling GC changed the YJIT-on numbers by only ~7%, ruling out GC barriers as the driver; the native profile above identifies the initiator. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126720] [Ruby Bug#22316] String#bit_set can access out-of-bounds memory after reentrant Warning.warn mutation
by cozerercument (Boran Per) 14 Sep '26

14 Sep '26

Issue #22316 has been reported by cozerercument (Boran Per). ---------------------------------------- Bug #22316: String#bit_set can access out-of-bounds memory after reentrant Warning.warn mutation https://bugs.ruby-lang.org/issues/22316 * Author: cozerercument (Boran Per) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-14T08:30:15Z master 03a426ec8d) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `String#bit_set` can access memory outside the current String backing buffer when a chilled String is mutated reentrantly from a customized `Warning.warn` callback. The bit offset is validated against the String length before `rb_str_modify()` is called. For a chilled String, `rb_str_modify()` can emit a deprecation warning and invoke Ruby-level `Warning.warn`. If that callback shrinks/reallocates the same String, the previously validated offset becomes stale. After the callback returns, `String#bit_set` continues using that offset without re-validating it against the new String length. With an AddressSanitizer build this produces a deterministic heap-buffer-overflow. ## Tested revision ```text ruby 4.1.0dev (2026-09-14T08:30:15Z master 03a426ec8d) +PRISM [x86_64-linux] ``` Commit: ```text 03a426ec8d30929558bf1244b4ad95eb7e1f54d2 ``` ## Reproduction Build Ruby with AddressSanitizer enabled and run: ```ruby $VERBOSE = true Warning[:deprecated] = true $victim = "A" * 8192 $reentered = false module ReallocateWarning def warn(message, category: nil, **kwargs) if category == :deprecated && !$reentered $reentered = true STDERR.puts "[+] callback entered" STDERR.puts "[+] before clear: #{$victim.bytesize}" $victim.clear $victim << ("B" * 1024) STDERR.puts "[+] after rebuild: #{$victim.bytesize}" return nil end super end end Warning.extend(ReallocateWarning) STDERR.puts "[*] initial size=#{$victim.bytesize}" # Valid against the original 8192-byte String. $victim.bit_set(7000 * 8) STDERR.puts "[!] bit_set returned normally" ``` Run with: ```sh ASAN_OPTIONS="detect_leaks=0:halt_on_error=1:abort_on_error=1" \ ./miniruby poc_single_bit_reentrant.rb ``` ## Actual result The callback shrinks the String from 8192 bytes to 1024 bytes: ```text [*] initial size=8192 [+] callback entered [+] before clear: 8192 [+] after rebuild: 1024 ``` AddressSanitizer then reports: ```text ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1 ``` Relevant stack: ```text str_apply_bit_mask ../string.c:7097 str_mutate_single_bit ../string.c:7175 str_mutate_bit ../string.c:7191 rb_str_bit_set ../string.c:7246 ``` The process aborts with exit status `134`. ## Expected result Reentrant mutation during the warning callback should not leave a previously validated bit offset usable against the new, smaller String buffer. The operation should either revalidate the bounds against the current String state or fail safely. ## Root cause The offset is checked against `RSTRING_LEN(str)` before `rb_str_modify(str)`. `rb_str_modify()` may invoke the deprecation-warning path for a chilled String, which can call a customized Ruby-level `Warning.warn`. That callback can mutate and shrink/reallocate the same receiver. After `rb_str_modify()` returns, the implementation obtains the current `RSTRING_PTR(str)`, but continues using the offset validated against the old String length without checking it again against the current `RSTRING_LEN(str)`. The region form of the bit-mutation APIs appears to be affected by the same reentrancy issue, but the single-bit example above is the minimal reproducer. I also verified that the underlying single-bit check/modify/access ordering existed before the recent region-argument change, so I am not attributing introduction of the issue to that change. ---Files-------------------------------- poc_single_bit_reentrant.out (8.12 KB) poc_single_bit_reentrant.rb (8.73 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126087] [Ruby Bug#22196] Heap-use-after-free in `fiber_switch` with transfer-terminated async tasks on 3.4.10
by scohen-tines (seth cohen) 14 Sep '26

14 Sep '26

Issue #22196 has been reported by scohen-tines (seth cohen). ---------------------------------------- Bug #22196: Heap-use-after-free in `fiber_switch` with transfer-terminated async tasks on 3.4.10 https://bugs.ruby-lang.org/issues/22196 * Author: scohen-tines (seth cohen) * Status: Open * ruby -v: ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- # Heap-use-after-free in `fiber_switch` reading terminated fiber's status (regression via Bug #21955 backport) Ruby 3.4.10 intermittently segfaults while an async-http workload terminates task fibers after truncated chunked HTTP responses. The equivalent workload completed 20 high-churn attempts on Ruby 3.4.9 without a crash. ASan shows a heap-use-after-free: the outgoing fiber's `rb_fiber_t` is freed by GC while `fiber_switch` still reads its status on the `Fiber#transfer` path. ## Environment ```text ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [aarch64-linux] ``` - Linux `aarch64` Docker image. - `async-1.32.1`, `async-http-0.64.2`, and `async-pool-0.10.3`. - The ASan build uses `-fsanitize=address -fno-omit-frame-pointer -g -O0` and has YJIT disabled. ## Expected behavior An incomplete chunked HTTP response should fail its async task with `EOFError`; the VM should not crash while cleaning up the task fiber. ## Actual behavior Ruby exits with a segmentation fault in the fiber stack pool: ```text -- C level backtrace -- fiber_pool_stack_release fiber_stack_release fiber_switch rb_fiber_start ``` One GDB run on a source-built 3.4.10 reached: ```text #0 fiber_pool_stack_release (stack=0xffffc4012ea0) at cont.c:770 pool = 0x0 #1 fiber_stack_release (fiber=0xffffc4012b00) at cont.c:903 #2 fiber_switch (...) at cont.c:2728 ``` We first hit this in a production service; the harness below reproduces the same C-level frames using only async-http against a local server, with no application code. ## AddressSanitizer result An ASan build makes the bug deterministic. With 50 in-process request bursts, all five stock 3.4.10 runs report: ```text ERROR: AddressSanitizer: heap-use-after-free READ of size 1 #0 fiber_switch /src/ruby-3.4.10/cont.c:2727 ... freed by thread T2 here: cont_free /src/ruby-3.4.10/cont.c:1079 fiber_free /src/ruby-3.4.10/cont.c:1164 ... previously allocated by thread T3 here: fiber_t_alloc /src/ruby-3.4.10/cont.c:1986 SUMMARY: AddressSanitizer: heap-use-after-free /src/ruby-3.4.10/cont.c:2727 in fiber_switch ``` Line 2727 of `cont.c` is the new `FIBER_TERMINATED_P(fiber)` condition (see Regression candidate below). Thus the first invalid operation is reading the freed `rb_fiber_t` object's status. It occurs before `fiber_pool_stack_release`; the latter is a downstream manifestation when the stale status reads as terminated and the release branch continues. The full report is attached as `stock-1.log`. ## Minimal reproduction harness The attached harness consists of: - `repro.rb`: local raw HTTP server plus direct async-http client; - `Gemfile` and `Gemfile.lock`: pinned async dependencies; - `Dockerfile` and `run.sh`: repeat the workload on a stock Ruby image. Run: ```sh ./run.sh 3.4.10 20 ``` This is probabilistic; successful runs are expected. The harness retains a log for every attempt and reports the first interpreter crash. The workload synchronizes groups of ten failures by default: ```sh FAULT_BARRIER=10 ./run.sh 3.4.10 50 ``` Run the same source comparison under ASan (deterministic): ```sh BATCHES=50 ./run-asan.sh 5 ``` `./run.sh 3.4.9 20` completes all 20 attempts without a crash; 3.4.9 predates the `148f263a` backport. ## Regression candidate Ruby 3.4.10 includes ruby_3_4 commit [`148f263a`](https://github.com/ruby/ruby/commit/148f263a0d299e4532c753470a282144c9104820), the backport of [`dc1777d`](https://github.com/ruby/ruby/commit/dc1777d01770ab62ec99ff6fa4cf622098f44968) for [Bug #21955](https://bugs.ruby-lang.org/issues/21955). That changes `fiber_switch` as follows: ```diff - if (resuming_fiber && FIBER_TERMINATED_P(fiber)) { + if (FIBER_TERMINATED_P(fiber)) { fiber_stack_release(fiber); } ``` `Fiber#transfer` passes a null `resuming_fiber`, so the old condition short-circuited without reading `fiber->status`. The new condition dereferences the stale `fiber` pointer before deciding whether to release its stack. We have not tested ruby-head/3.5, but the same condition is present there since `dc1777d`, so we expect it to be affected. ## Controlled source comparison The harness also includes: ```sh BATCHES=20 ./run-ab.sh 20 ``` It builds the published Ruby 3.4.10 source twice with the same compiler and workload: 1. stock 3.4.10; 2. 3.4.10 with only the above condition restored to `resuming_fiber && FIBER_TERMINATED_P(fiber)`. | Build | Attempts | `fiber_pool_stack_release` crashes | | --- | ---: | ---: | | stock 3.4.10 | 20 | 4 | | 3.4.10 with Bug #21955 condition reverted | 20 | 0 | The stock run also had one additional process abort with: ```text malloc(): unaligned tcache chunk detected ``` All 20 reverted-build processes completed successfully. These runs used `BATCHES=20`, 100 requests per batch, concurrency 20, and a barrier of 10 simultaneous truncated responses. The image is built from the Ruby 3.4.10 release tarball with `-O0 -g3 -fno-omit-frame-pointer`; the only source difference between the two images is the condition shown above. The ASan A/B uses `BATCHES=50`: all 5 stock runs report the above heap-use-after-free, while all 5 reverted runs complete cleanly. ## Request Could the fiber maintainers review why a `rb_fiber_t` can be finalized by GC while `fiber_switch` still holds it as the outgoing fiber? Reinstating the `resuming_fiber` guard avoids the dereference on the transfer path, but a proper fix likely needs to ensure that the outgoing fiber remains live through the switch or otherwise avoid reading it after its lifetime ends. ---Files-------------------------------- ruby-3.4.10-fiber-uaf.tar.gz (19.7 KB) stock-1.log (58.4 KB) -- https://bugs.ruby-lang.org/

4 5