[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #2320 [Tor Client]: var_cell_t with payload_len 0 risky



#2320: var_cell_t with payload_len 0 risky
------------------------+---------------------------------------------------
 Reporter:  arma        |       Owner:     
     Type:  defect      |      Status:  new
 Priority:  normal      |   Milestone:     
Component:  Tor Client  |     Version:     
 Keywords:              |      Parent:     
------------------------+---------------------------------------------------
 In fetch_var_cell_from_buf(), we do
 {{{
   length = ntohs(get_uint16(hdr+3));
 ...
   result = var_cell_new(length);
 }}}

 If length is 0, then in var_cell_new() we do
 {{{
   var_cell_t *cell = tor_malloc(sizeof(var_cell_t)+payload_len-1);
 }}}
 causing cell->payload to point to unallocated space.

 I looked through the code and didn't find any cases where we indirect into
 cell->payload when length is 0.

 But we should fix it, especially because in git master, we call
 {{{
   evbuffer_remove(buf, cell->payload, cell_length);
 }}}
 from inside fetch_var_cell_from_evbuffer(), and I don't want to rely on
 any particular behavior from libevent here. (Somebody should in fact check
 that libevent doesn't indirect into the pointer you hand it if length is
 0.)

 Reported by doors. He reported it with the phrase "lets assume no
 alignment", but I think alignment is not relevant here -- even if
 var_cell_t is padded internally, we're still going to fail to allocate
 that last byte, which is where cell->payload will be.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2320>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs