Bug #18343: empty hash passed to Array#pack causes Segmentation fault (2.6)

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.6.8p205 (2021-07-07 revision 67951) [x86_64-linux]
• Backport: 2.6: REQUIRED, 2.7: DONTNEED, 3.0: DONTNEED

[Ethan (Ethan -)]

passing an empty hash to Array#pack segfaults from ruby 2.4 to ruby 2.6 on ubuntu, macos, and windows.

[0].pack('c', {})

pack takes a keyword argument, and handles unknown keywords, but the empty hash segfaults.

here is the error trace in a github workflow running only the above expression: https://github.com/notEthan/jsi/runs/4226433638 (other ruby versions and OSes are part of the same run)

[xtkoba (Tee KOBAYASHI)]

Proposed patch:

--- ruby-2.6.8/pack.c.orig
+++ ruby-2.6.8/pack.c
@@ -330,7 +330,7 @@ pack_pack(int argc, VALUE *argv, VALUE a
 	if (buffer != Qundef && !RB_TYPE_P(buffer, T_STRING))
 	    rb_raise(rb_eTypeError, "buffer must be String, not %s", rb_obj_classname(buffer));
     }
-    if (buffer)
+    if (buffer && buffer != Qundef)
 	res = buffer;
     else
 	res = rb_str_buf_new(0);

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed
• Backport changed from 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN to 2.6: REQUIRED, 2.7: DONTNEED, 3.0: DONTNEED

This is definitely a bug in ruby 2.4 - 2.6, but ruby 2.4 and 2.5 are end of life, and ruby 2.6 is in security maintenance mode. I don't think this is a security issue, but just in case, I'll mark this for backporting for ruby 2.6. It is up to the ruby 2.6 branch maintainer whether it is actually backported.

[Ethan (Ethan -)]

agreed that it's not a security issue, and questionable whether it's worth fixing for a version near EOL. I only encountered this during an early/flawed attempt at generic argument delegation to some Array methods, but that has been rewritten and this issue does not affect me. a segfault in a supported Ruby still seemed worth reporting, but not fine to close.

[jeremyevans0 (Jeremy Evans)]

It's fixed in the master branch of Ruby, that's why it is closed. It's marked for backporting, because that is how backport requests are handled in Redmine. Doing this includes the issue in the list of backportable issues for 2.6 (https://bugs.ruby-lang.org/projects/ruby-master/issues?query_id=171).

[Ethan (Ethan -)]

oops, in writing that last sentence a "not" slipped by me and I said the opposite of what I meant to say. I meant to say "seemed worth reporting, but fine to close." did not mean to complain about the closing, brainfart.