Control: severity -1 important
Hi,
On Sun, Jul 06, 2014 at 04:00:29PM +0200, Zakaria ElQotbi wrote:
> Package: libapt-pkg4.12
> Version: 1.0.5
> Severity: grave
> Justification: renders package unusable
Thanks for the report!
These bugs are traditionally hard to tackle as they are hard to
reproduce (if at all possible). They depend on the order of sources.list
entries and the contents of the files downloaded as a result of that.
I am therefore downgrading a bit as this will resolve itself very very
likely with the next 'apt-get update'. Alternatively the posted
workaround works just as well. (and because you can hit it with any
version of apt from the last four years – so an RC-bugs would at the
most discourage people from upgrading to a security fix we had
recently…)
That said, I happen to know what is wrong this time as I saw it while
rewriting this codearea for a (still unfinished… damn) experimental
branch, which should have been public weeks ago… anyway, the simple fix
is in our debian/sid branch now waiting for the next upload.
As a (very) small reward for reporting this issue: The workaround will
actually make apt's cache generation slightly faster and is totally
harmless (if you don't happen to use insane high values, the equivalent
of 100MB should be enough, the current default is ~25MB). It is "very
small" though as it is probably not measurable…
Technical background:
In the dark ages (=before squeeze) if the cache was too small apt would
just error out ("mmap ran out of room"). In many many iterations
I worked on making the cache generation relocatable at runtime, so that
we can grow the underlying mmap by moving to a different address (as
growing but keeping the address is unlikely to work). We can't just
increase the cache size by default as on embedded devices we would eat
a good part of the available RAM this way… really bad if the kernel
OOM-killer is triggered…
The offender here is the line:
Ver->Section = UniqFindTagWrite("Section");
So the compiler figures out the storage location (Ver->Section), then
it calculates the value (return value of the function call) and stores
the value at the storage location – just that this is the old location
as the function call could potentially move the mmap… segfault.
So the solution is something like:
tempvalue = UniqFindTagWrite("Section");
Ver->Section = tempvalue;
Seems trivial, right? It is also the reason why regardless of how hard
you try to find all these instances, one or two are always slipping
through (but after 4 years, there can't be that many left, right? ;) )
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: Digital signature