[ruby-core:17463] Re: Ruby 1.9.0/1.8.7/1.8.6/1.8.5 new releases (Security Fix)

From: "Urabe Shyouhei" <[e-mail]>
> Bill Kelly wrote:
>>
>> Note, still getting this seg fault as of svn revision 17730
>> on 1_8_6 branch:
>>
>> $ ruby -ve 'str = "A"*(2**16) ; loop{ str << str ; puts str.size }'
>> ruby 1.8.6 (2008-06-29 patchlevel 255) [i686-linux]
>> 131072
>> -e:1: [BUG] Segmentation fault
>
> Sorry, cannot reproduce on my machine.  Does anyone have more info?

Hmm.. odd.

The above was on debian sarge, i686 arch. . .

I can also reproduce it on debian etch, x86_64 arch:

$ ./miniruby -ve 'str = "A"*(2**16) ; loop{ str << str ; puts str.size }'
ruby 1.8.6 (2008-06-29 patchlevel 255) [x86_64-linux]
131072
262144
524288
1048576
2097152
4194304
-e:1: [BUG] Segmentation fault
ruby 1.8.6 (2008-06-29) [x86_64-linux]


As well as win32, using visual studio.net 2003:

$ .\miniruby.exe -ve "str = 'A'*(2**16) ; loop{ str << str ; puts str.size }"
ruby 1.8.6 (2008-06-29 patchlevel 255) [i386-mswin32_71]
-e:1: [BUG] Segmentation fault


Am I checking out from the correct branch?  I am using:

svn co http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_6

Checked out revision 17730.


Here is some info about where the seg fault occurs:

0 miniruby.exe!str_buf_cat()  Line 720 + 0x17
1 miniruby.exe!rb_str_buf_append(unsigned long str=10552920, unsigned long str2=10552920)  Line 781 + 0x17
2 miniruby.exe!rb_str_append(unsigned long str=10552920, unsigned long str2=10552920)  Line 802 + 0xd
3 miniruby.exe!rb_str_concat(unsigned long str1=10552920, unsigned long str2=10552920)  Line 837 + 0xd


  static VALUE
  str_buf_cat(str, ptr, len)
      VALUE str;
      const char *ptr;
      long len;
  {

  // ...

      memcpy(RSTRING(str)->ptr + RSTRING(str)->len, ptr, len);
  00453189  mov         ecx,dword ptr [len]            // [ebp+10h]
  0045318C  mov         esi,dword ptr [ptr]            // [ebp+0Ch]
  0045318F  mov         edx,dword ptr [str]            // [ebp+8]
  00453192  mov         edi,dword ptr [edx+0Ch]
  00453195  mov         eax,dword ptr [str]            // [ebp+8]
  00453198  add         edi,dword ptr [eax+8]
  0045319B  mov         edx,ecx
  0045319D  shr         ecx,2
* 004531A0  rep movs    dword ptr [edi],dword ptr [esi]  // crash here
  004531A2  mov         ecx,edx
  004531A4  and         ecx,3
  004531A7  rep movs    byte ptr [edi],byte ptr [esi]

EAX = 00A10658 EBX = 7FFD5000 ECX = 00003E64 EDX = 00010000 ESI = 00A42000
EDI = 00A62010 EIP = 004531A0 ESP = 0012E528 EBP = 0012E540 EFL = 00010206
CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 003B GS = 0000
OV = 0 UP = 0 EI = 1 PL = 0 ZR = 0 AC = 0 PE = 1 CY = 0

ecx is 0x3e64, so I guess it copied about (0x4000 - 0x3e64)<<2 == 1648
bytes before dying.

Variables like total and capa seem pretty reasonable:

  str     10552920        unsigned long
  ptr     0x00a41990      const char *
  len     65536   long
  total   131072  long
  capa    131074  long

Strangely, the first eight bytes at [ptr] seem like junk?

0x00A41990  08 10 a5 00 78 01 98 00 41 41 41 41 41 41 41 41  ..x.?.AAAAAAAA
0x00A419A0  41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
0x00A419B0  41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
0x00A419C0  41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA


Regards,

Bill