Hi, Back in March of this year, I was working on fuzzing-related code, mostly about kernel-land testing (ex. filesystem code). I gave the initial code of a tool to a Red Hat employee in charge of QA related tasks (after showing some issues in iso9660 and jfs). During the next months the code was subject of cosmetic changes, and he added some improvements (split the test procedure in another file, added gfs and hfs support, improved usability). Few days ago the interest suddenly raised as he found out that nearly all the filesystems supported in the latest Linux kernel revision are affected by one or more issues (at very least, a denial of service concerning a specific operation such as read, write, etc, normally causing a so-called softlock-up/oops or a hardlock/panic/fs corruption). Another Red Hat employee, excited about the tool, 'leaked' the URL to the LKML [2][3] (even if code was available in a publicly accessible repository it wasn't being distributed actively). As usual, it didn't bother much the people there ;-) I had interest on tracking down the issues found with the tool, not just for curiosity. The feeling about 'silent patches' [1] became stronger when I realized that there was no intention for doing this publicly by other parties (cough). This is sadly, a common practice everywhere. Thanks to this and some other goodies, The Month of Kernel Bugs will start on 1st November, and will be announced this next Monday (30 Oct). I'm looking for other people interested on providing bugs for XNU (also for the "good old" Darwin), win32, *BSD, etc. If you want to contribute, drop me a line. Please note that only 'fresh', unknown bugs will be accepted, and submissions should be briefly documented. The goal is disclosing a kernel bug (DoS, privilege escalation, whatever interesting) on a daily basis for November. Watch out for silent patches in the git repositories, obscured bugzilla entries and the usual FUD. It doesn't hurt to get ready for the usual madness. Note that 'silent' doesn't necessarily mean 'covered up'. But just improperly described/not considered a security issue. Anyway, regarding the tool, these are the filesystems currently supported (depends on the packages you have installed in the system but these are all the supported ones right now, as of 0.6): [root@fedoravm fsfuzzer-0.6-lmh]# ./fsfuzz --help ./fsfuzz (ext3|ext2|vfat|msdos|swap|squashfs|xfs|hfs|gfs2|ntfs|reiserfs|jffs2|iso9660|cramfs| jfs|minix|bfs) Tarball available at: http://projects.info-pull.com/mokb/fsfuzzer-0.6-lmh.tgz And today's partial bugs list: http://projects.info-pull.com/mokb/fs-bugs-23-10-2006.txt.asc Key will be made available after November. This is for verification purposes. Hopefully they will still work by that time, so it shouldn't be necessary. Usual disclaimer applies. If you sell or get money from a bug found with this tool, shame on you ;-). Also, most of the bugs you can actually find with it are already known, but it's always nice to hear about new details (and if you've ported it to some other platform, better). You're more than welcome to send them. They will be considered for release in the MoKB, crediting accordingly. Kind regards. [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209907 [2]: http://www.ussg.iu.edu/hypermail/linux/kernel/0610.2/1941.html [3]: http://www.ussg.iu.edu/hypermail/linux/kernel/0610.2/2169.html
