Bug#260767: double-free on small allocations causes infinite loop or SIGSEGV in malloc
severity 260767 minor
tags 260767 + wontfix
thanks
On Wed, Jul 21, 2004 at 11:16:04PM -0500, Jeff Licquia wrote:
> The severity deserves an explanation. I found this bug as part of my
> work on getting Debian in shape for LSB 2.0. It appears that test
> /tset/LSB.os/genuts/glob/T.glob 29 does a double-free which tweaks this
> bug. That test ends up succeeding, but the next test (test 30) hangs at
> the very first attempt to allocate memory through no fault of its own.
> This causes bogus test failures, which will have an impact on Debian's
> ability to certify under at least LSB 2.0. I suspect that the LSB 1.3
> version of this test will experience similar problems.
>
> One might argue that the LSB's double-free is the real problem, and I
> will indeed be working with the LSB people to get this problem solved.
> Unfortunately, it's very possible that the LSB will not be in a position
> to fix this bug in a timely manner, and thus it would be better to fix
> the underlying incorrect behavior in glibc.
>
> I won't argue with a severity adjustment, though.
>
> I will have to write a workaround patch to fix this problem, and will
> attach it to this bug report when it is ready.
As a courtesy to the tracking of LSB problems, I will not close this
bug. However, I do not believe it should be "fixed".
Under absolutely no circumstances would a "fix" be accepted upstream.
Affecting the performance or maintainability of a non-debugging malloc
implementation to handle invalid input is not worthwhile. The LSB
tests are not such special software as to penalize the fast-path
allocation of every other piece of software on a Debian system.
If the LSB people do not have an adequate process for handling bugs in
their tests, that's not glibc's problem. Even SPEC can manage this...
--
Daniel Jacobowitz
Reply to: