Re: What to do with a kernel bug which lets my package work result look bad ?
On Sun, 06 Sep 2015, Thomas Schmitt wrote:
> > Maybe it should instead drop the long name, and return the ISOFS name,
> > instead.
>
> This might reduce the probability of a name collision,
> but can still collide with some short Rock Ridge name.
Any name we return can colide, unless we return something that is impossible
for isofs + extensions to return in the first place.
> Better would probably be a hash text derived from all
> available information about the file, which is not very
> much at that level of code, i fear.
We could do that, yes.
> But the actually needed fix is the protection of the
> innocent.
Yes. It matters little what kind of insanity results from a corrupt/broken
filesystem, as long as we defang it enough for it to not be a viable way to
attack userspace apps.
> > However, one has to check the code throughoutly to ensure it can deal with
> > the 255-bytes size.
>
> Will dive into the code and already began to read
> http://kernel-handbook.alioth.debian.org
>
> Maybe i can make experiments with s/254/256/ and/or
> with truncation to exactly the assumed maximum size.
Just add a strncat or something like that to add as much as possible from
the current chunk, but ensure the end result is no bigger than 255 chars +
NUL, and that it is in fact always NUL-terminated.
I'd check the buffer size where the chunks are being copied to first,
though. It might be 255, in which case it needs to grow by a byte.
> > Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical
> > way to go about it, I guess.
>
> Shall i do already now or better after i exhausted my code reading
> skills and/or managed to get a kernel running with s/254/256/ ?
You can open that report at any time, and send anything you discover as well
as debugging/fix patches to the bug report.
A minimal ISO image that shows the bug would be a nice attachment to the bug
report, too.
> > OTOH, it is a >10-year old bug, so there are some kudos and credit to be
> > proud of for anyone that fixes it :-)
>
> Is there a find-the-oldest-bug contest ?
Not that I know of, it is just a lot cooler than fixing recent bugs :p
> And is the list open for mere oddities, too ?
> (I have some Linux timestamp peculiarities of which i really
> don't know whether i shall replay them in libisofs.)
I wouldn't know. If it is caused by the usual POSIX braindeadness coupled
to some particular filesystem's timestamp precision, well...
OTOH, if it is a bug that can be either fixed or documented (when fixing it
would end up causing worse damage), it might be interesting.
> To our luck there are userland tools to read ISO 9660
> independently of the kernels. Among them is my xorriso.
Indeed...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: