wtetzner / bitstring

Automatically exported from code.google.com/p/bitstring
GNU General Public License v2.0
0 stars 0 forks source link

Permissive subbitstring allows a segmentation fault #16

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The following code:

let _ =
  let size = 1 in
  let off' = max_int + 1 in
  let len' = 64 in
  let bs = (String.create size, 0, size * 8) in
  let bs' = Bitstring.subbitstring bs off' len' in
  bitmatch bs' with
  | { 0L : 64 : int ; _ : -1 : bitstring } -> ()
  | { _ } -> ()

randomly produces a segmentation fault when ran under PowerPC-32 (both in 
bytecode and native runs). An overflow makes the test in Bitstring.subbitstring 
pass:

let subbitstring (data, off, len) off' len' =
  let off = off + off' in
  if len < off' + len' then invalid_arg "subbitstring";
  (data, off, len')

since off' + len' overflows and becomes negative.
The computed off also overflows, resulting in a bitstring with a negative 
offset.

When accessing this bitstring, the function 
ocaml_bitstring_extract_fastpath_int64_be_unsigned provokes a segmentation 
fault sometimes.

The "sometimes" part seems to be due to address space randomization. As a 
consequence, this bug is *not* reproducible with these particular values under 
gdb, which seems to desactivate address space randomization.
However, it is reproducible under valgrind:

==20554== Invalid read of size 4
==20554==    at 0x1001F28C: ocaml_bitstring_extract_fastpath_int64_be_unsigned 
(bitstring_c.c:132)
==20554==    by 0xFE93F72F: ???
==20554==  Address 0xf3209cc is not stack'd, malloc'd or (recently) free'd
==20554== 
==20554== 
==20554== Process terminating with default action of signal 11 (SIGSEGV)
==20554==  Access not within mapped region at address 0xF3209CC
==20554==    at 0x1001F28C: ocaml_bitstring_extract_fastpath_int64_be_unsigned 
(bitstring_c.c:132)
==20554==    by 0xFE93F72F: ???
==20554==  If you believe this happened as a result of a stack
==20554==  overflow in your program's main thread (unlikely but
==20554==  possible), you can try to increase the size of the
==20554==  main thread stack using the --main-stacksize= flag.
==20554==  The main thread stack size used in this run was 8388608.

The invalid read *does not* provoke a segmentation fault under x86_64 (no 
randomization?).

Possible fixes (bitstring.ml, subbitstring):
- test that len' is >= 0
- test that off + off' does not overflow
- test that off' + len' does not overflow

Original issue reported on code.google.com by valentin.robert.42 on 30 Mar 2012 at 11:41

GoogleCodeExporter commented 8 years ago
Patch proposed by mrvn, mimicking String.

Original comment by valentin.robert.42 on 30 Mar 2012 at 12:18

Attachments:

GoogleCodeExporter commented 8 years ago
The patch is a simple arithmetic manipulation of the original test, plus 
testing that off' and len' supplied by the user are not negative, so it makes 
sense.  I will apply it upstream in a moment.

Original comment by richard....@gmail.com on 30 Mar 2012 at 12:47

GoogleCodeExporter commented 8 years ago
Fixed in revision 193.

Original comment by richard....@gmail.com on 30 Mar 2012 at 12:49