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
