binary_to_term can crash the VM

Valentin Micic <>
Thu Feb 2 02:06:52 CET 2006


In addition to

binary_to_term(<<131,109,255,255,255,255>>)       (*1*)

Also crashing emulator are:

binary_to_term(<<131,109, 16#FFFFFFFC:4/big-unsigned-unit:4>>) .
binary_to_term(<<131,109,255,255,255,253>>).
binary_to_term(<<131,109,255,255,255,254>>).

Could it be that 32-bit data overflow is causing boundary check to fail and 
crash emulator, as in:

0xFFFFFFFC + 0x04 = 0x00000000, instead of  0x0100000000
0xFFFFFFFF + 0x04 = 0x00000003, instead of  0x0100000003

It would be great to find out what is going on.

(*1*) BACKGROUND:
The above is "external" representation of the binary term, without actual 
value. For example,  if you do

term_to_binary( <<3>> )  ->  <<131,109,0,0,0,1,3>>

where:

131      is Version Magic Number;
109      is TAG indicating binary term;
0,0,0,1 represents a length of the term in bytes (in this case 1 Byte),
3          is the actual value.

In all cases but the 4 indicated, when one attempts to convert the external 
representation to term, without value, say, by skipping 3 as in the example 
below:

binary_to_term( <<131,109,0,0,0,1>> ).

The emulator will report an error, like, {'EXIT', {badarg....}

Valentin.


----- Original Message ----- 
From: "Matthias Lang" <>
To: <>
Sent: Thursday, February 02, 2006 1:13 AM
Subject: binary_to_term can crash the VM


> Hi,
>
> I recall binary_to_list being fixed to be able to cope with 'bad'
> binaries a few years ago. But I stumbled across another way to crash
> it:
>
>  2> binary_to_term(<<131,109,255,255,255,255>>).
>  Segmentation fault
>
> This can bite when code such as 'rb' calls binary_to_term on corrupt
> data:
>
>  /usr/local/src/otp_src_R10B-8/bin/erl -boot start_sasl
>  ...
>  Eshell V5.4.10  (abort with ^G)
>  1> c(crash).
>  {ok,crash}
>  2> crash:go().
>  rb: reading report...Segmentation fault
>
> I haven't tried making dets fail, but I bet 'rb' isn't the only thing
> which uses binary_to_term on data it can't be sure it created.
>
> Matthias
>
> (FWIW: I don't use 'log_mf_handler' or 'rb' in production systems
> because of past problems. This seems like another good reason to give
> them a miss.)
>
> %%----------------------------------------------------------------------
> -module(crash).
> -export([go/0]).
>
> go() ->
>  file:make_dir("/tmp/zap"),
>  file:write_file("/tmp/zap/index", <<1>>),
>  %% simulate a corrupt logfile
>  file:write_file("/tmp/zap/1", <<0,6,131,109,255,255,255,255>>),
>  rb:start([{report_dir, "/tmp/zap"}]),
>  rb:list().
> 




More information about the erlang-questions mailing list