[tor-bugs] #20081 [Core Tor/Tor]: potential memory corruption in or/buffers.c (not exploitable)
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Sep 12 09:58:00 UTC 2016
#20081: potential memory corruption in or/buffers.c (not exploitable)
-----------------------------------------+---------------------------------
Reporter: asn | Owner:
Type: defect | Status: needs_review
Priority: Medium | Milestone: Tor:
| 0.2.9.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: 029-proposed tor-bug-bounty | Actual Points:
Parent ID: | Points: 0.3
Reviewer: | Sponsor:
-----------------------------------------+---------------------------------
Changes (by asn):
* status: new => needs_review
Comment:
Suggested patch by Guido accompannied by rationale:
----
{{{
diff --git a/d.c b/d.c
index 045a678..1a50261 100644
--- a/d.c
+++ b/d.c
@@ -29,8 +29,11 @@ static inline size_t
preferred_chunk_size(size_t target)
{
size_t sz = MIN_CHUNK_ALLOC;
+ size_t prev = 0;
while (CHUNK_SIZE_WITH_ALLOC(sz) < target) {
sz <<= 1;
+ tor_assert(sz > prev);
+ prev = sz;
}
return sz;
}
}}}
"It's agnostic as to whether the system is 32 or 64 bit, deals with the
core problem (preventing the actual overflow), and lets other functions
(such as ```tor_malloc```) deal with outrageous allocatiion
sizes if applicable. If you want proper error handling instead of a hard
abort through ```tor_assert()``` then more changes are necessarily, but
I'd say that since Tor's general memory consumption is at
present relatively frugal, attempts to allocate 2+ GB's of memory are an
indication that something is already amiss so an abort is the way to go."
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20081#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list