[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#550625: marked as done (libc6: Realloc sometimes fails to copy all memory correctly)



Your message dated Sun, 18 Oct 2009 16:58:31 +0200
with message-id <20091018145831.GA625@volta.aurel32.net>
and subject line Re: libc6: Realloc sometimes fails to copy all memory correctly
has caused the Debian Bug report #550625,
regarding libc6: Realloc sometimes fails to copy all memory correctly
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
550625: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550625
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.7-18
Severity: normal

I've been trying to track down a bug that became apparent when using Tor. Sometimes,
realloc apparently failed to copy the last few bytes of a buffer over when it enlarged
said buffer.

I've done some digging, and came across a bugreport about the issue:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=10018 

Also, I found a glibc bugreport with an attached patch to
fix the problem, but the patch was rejected by the glibc maintainer:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5743
a few months later though, the fix was applied:
http://repo.or.cz/w/glibc.git?a=commitdiff;h=486bdb886330a250af76cbb12af55d2c67ec0981

I checked Lenny's sources, and the offending line in malloc.c is the same as in
the bugreports above, Squeeze, due to updating to a newer version of libc,
doesn't have it.

I'm not sure why the test programs referenced don't trigger the bug on Lenny
for me, but when patching the Tor source to manually compare the last few bytes
of a buffer before it is realloc'ed to afterwards exhibits the issue.


-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1                      1:4.3.2-1.1 GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
pn  glibc-doc                     <none>     (no description available)
ii  libc6-i686                    2.7-18     GNU C Library: Shared libraries [i
ii  locales                       2.7-18     GNU C Library: National Language (

-- debconf information excluded




--- End Message ---
--- Begin Message ---
Version: 2.9-1

On Sun, Oct 11, 2009 at 04:42:35PM +0200, Sebastian Hahn wrote:
> Package: libc6
> Version: 2.7-18
> Severity: normal
> 
> I've been trying to track down a bug that became apparent when using Tor. Sometimes,
> realloc apparently failed to copy the last few bytes of a buffer over when it enlarged
> said buffer.
> 
> I've done some digging, and came across a bugreport about the issue:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=10018 
> 
> Also, I found a glibc bugreport with an attached patch to
> fix the problem, but the patch was rejected by the glibc maintainer:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=5743
> a few months later though, the fix was applied:
> http://repo.or.cz/w/glibc.git?a=commitdiff;h=486bdb886330a250af76cbb12af55d2c67ec0981
> 
> I checked Lenny's sources, and the offending line in malloc.c is the same as in
> the bugreports above, Squeeze, due to updating to a newer version of libc,
> doesn't have it.
> 

Marking the bug as fixed in version 2.9-1. A new version will be
uploaded to lenny with this fix.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net


--- End Message ---

Reply to: