[tor-bugs] #18162 [Tor]: Potential heap corruption in smartlist_add(), smartlist_insert()
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Jan 30 08:10:54 UTC 2016
#18162: Potential heap corruption in smartlist_add(), smartlist_insert()
-------------------------------------------------+-------------------------
Reporter: asn | Owner: nickm
Type: defect | Status:
Priority: High | needs_review
Component: Tor | Milestone: Tor:
Severity: Normal | 0.2.8.x-final
Keywords: security 025-backport 026-backport | Version:
027-backport 024-backport | Resolution:
Parent ID: | Actual Points:
Sponsor: | Points:
-------------------------------------------------+-------------------------
Comment (by cypherpunks):
Replying to [comment:11 nickm]:
> > The value range of size_t can be smaller than int.
> > Integer types are allowed to have padding bits.
>
> I'd be fine with compile-time fixes for both of these. How about
something like
> {{{
> #if SIZE_MAX < INT_MAX
> #error
> #endif
> }}}
> for the first one, and something like
> {{{
> #if SIZE_MAX/SIZEOF_VOID_P > INT_MAX
> ...
> #endif
> }}}
> for the second ?
That looks good and should be portable.
> (I do not expect to start supporting segmented memory models or weird
padded ints.)
That's reasonable.
There is a chance that the padding might happen with some debug or
hardening configurations on a mainstream platform like clang/x86. The
padding bits could be used for tracking uninitialized usage or concurrent
access (data races) and on x86 with no penalty for unaligned access some
arbitrary number of padding bits/bytes could be used (potentially
different for signed/unsigned types). So the compile-time check should be
there.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18162#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list