Project

General

Profile

Actions

Bug #8864

closed

sprintf segfaults with too high precision

Added by Aaronneyer (Aaron Neyer) about 11 years ago. Updated about 11 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
-
[ruby-core:57023]

Description

In any Ruby version (attempted with 1.8.7, 1.9.3, and 2.0.0), specifying a very large precision in sprintf can cause a segmentation fault.

The following code will cause the segmentation fault.

"%.99999f" % 10

The number to cause a segfault is dependent on the system. On my laptop, any number above 1100 would cause it, and on an EC2 micro instance, around 2500 was the limit.


Files

vsnprintf.patch (1.39 KB) vsnprintf.patch phasis68 (Heesob Park), 09/12/2013 07:44 PM
Actions #1

Updated by nobu (Nobuyoshi Nakada) about 11 years ago

  • Project changed from 14 to Ruby master
Actions #2

Updated by nobu (Nobuyoshi Nakada) about 11 years ago

  • Tracker changed from Feature to Bug

Updated by utkarshkukreti (Utkarsh Kukreti) about 11 years ago

I'm trying to write a patch for this (my first contribution actually), and I'll really appreciate some help.

I've found the cause -- the buffer sent to cvt() function in vsnprintf.c is allocated on the stack with a fixed size of #define BUF (MAXEXP+MAXFRACT+1) here which on my machine is 1024 + 64 + 1 == 1089, and the data is written to it without any bounds check, which causes the segfault.

I can think of two possible solutions:

  1. Limit the precision a user can specify on a call to sprintf to MAXFRACT.
  2. malloc the actual required memory when it's greater than the defined constant BUF, and free it before returning from the function.

I think (2) is the best solution here.

What do you all think? Also, what functions should I use to allocate/free memory inside vsnprintf?

Actions #4

Updated by utkarshkukreti (Utkarsh Kukreti) about 11 years ago

Ok, (1) is not really an option, all other languages I looked at support arbitrary value of precision.

Updated by phasis68 (Heesob Park) about 11 years ago

I made a patch for this issue.

Actions #6

Updated by nobu (Nobuyoshi Nakada) about 11 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r42918.
Aaron, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


vsnprintf.c: fix buffer overflow

  • vsnprintf.c (MAXEXP, MAXFRACT): calculate depending on constants in
    float.h.
  • vsnprintf.c (BSD_vfprintf): limit length for cvt() to get rid of
    buffer overflow. [ruby-core:57023] [Bug #8864]
  • vsnprintf.c (exponent): make expbuf size more precise.

Updated by nagachika (Tomoyuki Chikanaga) about 11 years ago

  • Backport set to 1.9.3: REQUIRED, 2.0.0: REQUIRED
  • ruby -v set to -

Updated by nagachika (Tomoyuki Chikanaga) about 11 years ago

  • Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED to 1.9.3: REQUIRED, 2.0.0: DONE

Backported 42908 (for resolve conflict) and 42918 to ruby_2_0_0 at r42944.

Updated by usa (Usaku NAKAMURA) about 11 years ago

  • Backport changed from 1.9.3: REQUIRED, 2.0.0: DONE to 1.9.3: DONE, 2.0.0: DONE

Backported to ruby_1_9_3 at r43488.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0