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

[ruby-core:126779] [Ruby Bug#22335] Stack corruption with >31 keyword args and refined Integer#==
by eapache_opslevel (Evan Huus) 09 Oct '26

09 Oct '26

Issue #22335 has been reported by eapache_opslevel (Evan Huus). ---------------------------------------- Bug #22335: Stack corruption with >31 keyword args and refined Integer#== https://bugs.ruby-lang.org/issues/22335 * Author: eapache_opslevel (Evan Huus) * Status: Open * ruby -v: 4.0.7 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is a messy one that originally surfaced as a flaky test in our Rails app, and required a lot of AI-assisted debugging to track down. This bug appears in the latest 4.0.7, though all of the original investigation was done against 3.3.11. If you have: - a method that takes only keyword args - has >31 keyword args - has a call-time-evaluated default value (e.g. `{}`) at argument index >31 - running in a Ruby process that has refined `Integer#==` at any point Then you get inconsistent stack corruption depending on your process's hash salt. The mechanism is nasty: - In a method with only keyword args, `vm_call_iseq_setup_kwparm_kwarg()` call `args_setup_kw_parameters()` with `klocals = argv + kw_param->bits_start - kw_param->num`, i.e. **above `cfp->sp`**, without first extending `cfp->sp` over those locals - `args_setup_kw_parameters()` uses a full hash, keyed by integer, for arguments beyond index 31 - When `args_setup_kw_parameters()` sets a key in that hash, and that key collides with another (not uncommon for a tiny hash, but still salt-dependent), it triggers an integer comparison - The refinement on `Integer#==` prevents that comparison from taking the fast path and turns it into a real C frame - Which gets pushed onto the stack, when the stack pointer hasn't been extended - Thus overwriting the other args and producing garbage The net effect is that the called method sees garbage values for the overwritten arguments. I've attached a reproducing script, which is unfortunately complex, as it needs to do some work to intentionally hit the correct hash collision depending on the process's salt. A simpler static version doesn't reproduce reliably enough to be useful. Even this version will occasionally get a hash salt with no collisions and fail to reproduce, though that seems pretty rare on my machine. ---Files-------------------------------- repro.rb (1.51 KB) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126825] [Ruby Bug#22340] Win32: File.stat succeeds on symbolic-link loops on Windows
by nobu (Nobuyoshi Nakada) 09 Oct '26

09 Oct '26

Issue #22340 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22340: Win32: File.stat succeeds on symbolic-link loops on Windows https://bugs.ruby-lang.org/issues/22340 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- On Windows, `File.stat` succeeds on a self-referential symbolic link instead of raising `Errno::ELOOP`, and `File.exist?` returns `true`. Opening the same link raises `Errno::ELOOP`. I noticed this while adding symbolic-link tests to FileUtils, whose Windows CI reported the unexpected `File.exist?` result. ## Reproduction ````ruby require 'tmpdir' Dir.mktmpdir do |dir| Dir.chdir(dir) do File.symlink('a', 'a') p File.readlink('a') # => "a" p File.exist?('a') # => true; expected false p File.stat('a') # succeeds; expected Errno::ELOOP File.open('a') # raises Errno::ELOOP ensure File.unlink('a') if File.symlink?('a') end end ```` `File.lstat('a')` should continue to succeed and identify the entry as a symbolic link. ## Cause In `winnt_stat`, failure to open the resolved path falls back to `stat_by_find` unless `open_error` matches one of the listed errors. The symbolic-link-following implementation introduced in f5b96e594c769cf309b70fd7736caaf90372a3b6 retained this fallback, which was intended to handle sharing violations for files such as `pagefile.sys`. `ERROR_CANT_RESOLVE_FILENAME` is not listed, so a symbolic-link loop also reaches the fallback, which retrieves information about the link itself and reports success. -- https://bugs.ruby-lang.org/

3 2

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

09 Oct '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/

4 3

[ruby-core:126818] [Ruby Bug#22338] [Backport] win32: create directory symlinks for relative directory targets
by nobu (Nobuyoshi Nakada) 09 Oct '26

09 Oct '26

Issue #22338 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22338: [Backport] win32: create directory symlinks for relative directory targets https://bugs.ruby-lang.org/issues/22338 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- https://github.com/ruby/ruby/pull/17545 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126782] [Ruby Bug#22336] IO:Buffer Heap uaf
by danielchong (Daniel Chong) 09 Oct '26

09 Oct '26

Issue #22336 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22336: IO:Buffer Heap uaf https://bugs.ruby-lang.org/issues/22336 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0-dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, a UAF is possible in IO:Buffer. PoC: ``` $buf = IO::Buffer.new(64) evil = Object.new def evil.to_str $buf.resize(64 * 1024 * 1024) "UTF-8" end $buf.get_string(0, 32, evil) ``` ASAN (truncated): ``` ERROR: AddressSanitizer: heap-use-after-free ... READ of size 32 #3 str_enc_new string.c:1109 #4 io_buffer_get_string io_buffer.c:3276 <- USE (read from stale base) freed by thread T0 here: #0 realloc #1 rb_io_buffer_resize io_buffer.c:2203 <- FREE (realloc move) #2 io_buffer_resize io_buffer.c:2249 ... #16 rb_str_to_str string.c:1818 #18 name_for_encoding encoding.c:296 #20 rb_find_encoding encoding.c:345 #21 io_buffer_get_string io_buffer.c:3266 <- reentrancy boundary (encoding to_str) previously allocated by thread T0 here: #0 calloc #1 io_buffer_initialize io_buffer.c:216 <- original 64-byte INTERNAL buffer ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:126770] [Ruby Bug#22334] Assertion Failed: VM_ENV_FLAGS:FIXNUM_P(flags)
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 09 Oct '26

09 Oct '26

Issue #22334 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22334: Assertion Failed: VM_ENV_FLAGS:FIXNUM_P(flags) https://bugs.ruby-lang.org/issues/22334 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code: ```ruby def r; return **[nil]; end; r() ``` Resulted in this output: ``` ../vm_core.h:1554: Assertion Failed: VM_ENV_FLAGS:FIXNUM_P(flags) ruby 4.1.0dev (2026-09-15T05:36:12Z master 3296d5c99c) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- ../vm_core.h:1554: Assertion Failed: VM_ENV_FLAGS:FIXNUM_P(flags) ruby 4.1.0dev (2026-09-15T05:36:12Z master 3296d5c99c) +PRISM [x86_64-linux] Crashed while printing bug report Aborted (core dumped) ``` *This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)* -- https://bugs.ruby-lang.org/

4 3

[ruby-core:126738] [Ruby Bug#22322] AddressSanitizer: use-after-poison in econv_description /ruby-src/build/../transcode.c
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 09 Oct '26

09 Oct '26

Issue #22322 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22322: AddressSanitizer: use-after-poison in econv_description /ruby-src/build/../transcode.c https://bugs.ruby-lang.org/issues/22322 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following program: ```ruby ec = Encoding::Converter.new("", "xml_attr_content_escape") begin ec.dup.freeze; ec.clone(freeze: false); GC.start(full_mark: true, immediate_sweep: true); ObjectSpace.each_object(ec.class).first(50).each(&:inspect); rescue Exception; end # dataflow fusion ``` makes the interpreter report: ``` ================================================================= ==1596291==ERROR: AddressSanitizer: use-after-poison on address 0x79ce1cfff1f8 at pc 0x60e57424f1e5 bp 0x7ffd8f1a9020 sp 0x7ffd8f1a9018 READ of size 1 at 0x79ce1cfff1f8 thread T0 #0 0x60e57424f1e4 in econv_description /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../transcode.c:2069:9 #1 0x60e574254cfd in econv_inspect /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../transcode.c:3572:9 #2 0x60e57430c9b9 in vm_call0_cfunc_with_frame /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c:164:15 #3 0x60e57430c9b9 in vm_call0_cfunc /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c:178:12 #4 0x60e57430c9b9 in vm_call0_body /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c:229:15 #5 0x60e57430f704 in vm_call0_cc /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c:101:12 #6 0x60e57430f704 in rb_call0 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c:577:12 #7 0x60e5742c0b7c in rb_call /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c:896:12 #8 0x60e5742c0b7c in rb_funcall_with_block_kw /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c:1216:12 #9 0x60e574313e8e in vm_yield_with_symbol /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_insnhelper.c:5291:16 #10 0x60e5743134e1 in invoke_block_from_c_bh /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm.c:1912:16 #11 0x60e5742c10b3 in vm_yield_with_cref /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm.c:1946:12 #12 0x60e5742c10b3 in vm_yield /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm.c:1954:12 #13 0x60e5742c10b3 in rb_ec_yield /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_eval.c #14 0x60e57437fa35 in rb_ary_each /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../array.c:2792:9 #15 0x60e5742f720a in vm_call_cfunc_with_frame_ /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_insnhelper.c:3904:11 #16 0x60e5742e14b9 in vm_call_method_each_type /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_insnhelper.c:4896:16 #17 0x60e5742e0c4e in vm_call_method /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_insnhelper.c #18 0x60e5742a59ea in vm_sendish /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_insnhelper.c:6283:15 #19 0x60e5742a59ea in vm_exec_core /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../insns.def:864:11 #20 0x60e57428dbe1 in rb_vm_exec /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm.c:2881:22 #21 0x60e573ee5c1c in rb_ec_exec_node /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../eval.c:299:9 #22 0x60e573ee5c1c in ruby_r ``` To reproduce: ``` /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby --disable-gems --parser=parse.y /tmp/test.rb ``` Commit: ``` 3296d5c99ce005e4698fb27a405e01d766ad2647 ``` Build configuration: ``` ../configure --prefix=... CC=clang-18 cflags="-fsanitize=address -fno-omit-frame-pointer -DUSE_MN_THREADS=0" cppflags="-DRUBY_DEBUG=1" optflags="-O1" ``` Operating System: ``` Ubuntu 24.04 host, Docker ffe-ruby:latest ``` *This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)* -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126731] [Ruby Bug#22319] heap buffer overflow triggered by array's zip function
by danielchong (Daniel Chong) 09 Oct '26

09 Oct '26

Issue #22319 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22319: heap buffer overflow triggered by array's zip function https://bugs.ruby-lang.org/issues/22319 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi, I found a heap buffer overflow affecting array's zip functionality. PoC: ``` a = (1..3000).to_a evil = Object.new; $a = a def evil.to_ary; $a.clear; [1,2,3]; end a.zip(evil) ``` ASAN output (truncated): ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 8 ... #0 RARRAY_AREF internal/array.h:153 #1 rb_ary_zip array.c:4850 <-- USE (stale len) 0x... is located 0 bytes after 256-byte region [...] allocated by thread T0 here: #4 ary_heap_realloc array.c:396 #5 ary_resize_capa array.c:439 #6 rb_ary_clear array.c:4988 <-- SHRINK (via arg's to_ary) ... #18 convert_type_with_id object.c:3303 <-- take_items -> to_ary -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126730] [Ruby Bug#22318] heap uaf triggered in array.flatten
by danielchong (Daniel Chong) 09 Oct '26

09 Oct '26

Issue #22318 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22318: heap uaf triggered in array.flatten https://bugs.ruby-lang.org/issues/22318 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, there seems to be a bug in Array's flatten function. PoC: ``` a = (1..2000).to_a bad = Object.new $a = a def bad.to_ary; $a.clear; [1,2,3]; end a << bad a.flatten ``` ASAN output (truncated): ``` 7==ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 16000 ... thread T0 #3 ary_memcpy0 array.c:354 #4 ary_memcpy array.c:371 #5 flatten array.c:6715 <-- USE (stale count i) #6 rb_ary_flatten array.c:6924 0x... is located 0 bytes after 256-byte region [...] allocated by thread T0 here: #4 ary_heap_realloc array.c:396 #5 ary_resize_capa array.c:439 #6 rb_ary_clear array.c:4988 <-- SHRINK (via to_ary) ... #18 convert_type_with_id object.c:3303 #21 rb_check_array_type array.c:1032 #22 flatten array.c:6705 <-- reentrant conversion ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126719] [Ruby Bug#22315] heap-use-after-free in String unpack with a block that mutates the receiver
by danielchong (Daniel Chong) 09 Oct '26

09 Oct '26

Issue #22315 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22315: heap-use-after-free in String unpack with a block that mutates the receiver https://bugs.ruby-lang.org/issues/22315 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0-dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- PoC: s = "C" * 4000 s.unpack("L*") { s.clear } Asan (truncated): ERROR: AddressSanitizer: heap-use-after-free on address 0x... READ of size 4 ... thread T0 #3 bary_unpack_internal bignum.c:1179 #4 rb_integer_unpack bignum.c:3753 #5 pack_unpack_internal pack.c:1415 <-- USE 0x... is located 4 bytes inside of 4001-byte region [...] freed by thread T0 here: #2 ruby_xfree_sized gc.c:6295 #3 str_discard string.c:2840 #4 rb_str_clear string.c:6678 ... #16 rb_yield vm_eval.c #17 pack_unpack_internal pack.c:1416 <-- FREE (user block via rb_yield) -- https://bugs.ruby-lang.org/

4 4