On Sat, 05 Sep 2015, Thomas Schmitt wrote: > packages (*), i stumbled over a bug in fs/isofs/rock.c which > truncates filenames of length 254 or 255 to quite random > lengths and thus can let readdir(3) emit multiple identical > names in the same directory.
Ugh. Yeah, that code looks broken at first glance. Looks like it doesn't try to return as much as possible of a file name when it hits the character limit: it seems to just end the filename at the previous chunk. Maybe it should instead drop the long name, and return the ISOFS name, instead. Nasty crap will, of course, happen if there is a colision between the two namespaces. I don't know enough about Rock Ridge to know whether it mandates something specific in this regard. Whatever is done to fix this, it needs to properly handle 255-byte file names, anyway. A simple fix at first glance would be to append enough of the current chunk to hit exactly the 255-byte boundary, and truncate at that point. This would fix the issue for all valid ISOFS+RRIP filename sizes. However, one has to check the code throughoutly to ensure it can deal with the 255-bytes size. If it doesn't, that's a separate bug that needs fixing. > What to do now with this knowledge ? Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical way to go about it, I guess. You could just report in LKML as well, but then you must ask again should nobody reply after two weeks, etc. > Does Debian have a kernel department ? With round tuits ? We do, but they're often overworked. You can file a bug in the Debian BTS against the "linux" source package, which is the kernel. > (On LKML they will at best urge me to fix it myself. They'd like you to do that, I suppose, since nobody is really working on ISOFS. But this is a clear bug that hits legal filesystems, so it is not a "fix it yourself" deal. It MIGHT be a "fix it yourself if you want it done anytime soon", though :-( OTOH, it is a >10-year old bug, so there are some kudos and credit to be proud of for anyone that fixes it :-) > ISO 9660 driver. This constant "254" might have a good > reason. Who can tell ?) Most of the RRIP support in Linux ISOFS predates git (2.6.11/2.6.12), which kinda means in practice that you are better off analysing the code in depth to find out its limitations (and fix them). The code in fs/isofs/rock.c looks like it has lots of cowebs and some bitrot, though. -- "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