Re: What to do with a kernel bug which lets my package work result look bad ?

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Henrique de Moraes Holschuh wrote:
> Any name we return can colide, unless we return something that is impossible
> for isofs + extensions to return in the first place.

Rock Ridge permits any name of any length. Theoretically a NM
could contain NUL or '/' characters. (One should catch them.)
NM's specified purpose is "to support POSIX-style or other names".

It turned out that libisofs has half of the same problem as the
kernel.
Its constant LIBISOFS_NODE_NAME_MAX is 255 and causes mindless
truncation of names at this length. No provisions for uniqueness
or UTF-8 correctness to see. And of course no knowledge about
the neighbors in the same directory.

I will try to develop a solution in libisofs. Maybe it will
become suitable for the kernel, too.


i wrote:
> > 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.

I convinced myself that the two callers of the buggy function
can handle returned lengths up to 255 characters. (See #789300,
inspection of dir.c and namei.c)

Any proposals how to stress test my custom kernel ?

I tared up multiple times my /home backup ISO which contains
names up to 255 bytes, Mumbay song titles, and similar
challenges from working on backup topics.


Have a nice day :)

Thomas