5 ms·
Fuzzing is an incredibly useful technique for finding bugs in a codebase. But it should be noted that BUG() is the only valid response if your state is invalid.
by cyphar 11y ago
Fuzzing is an incredibly useful technique for finding bugs in a codebase. But it should be noted that BUG() is the only valid response if your state is invalid. Filesystems should never try to soldier on if their internal state becomes corrupted -- there lie dragons.
- asdfaoeu 11y agoThe correct response is to stop writing to the filesystem. They mean BUG as in it crashes the kernel. Having said that most Linux machines will not let you mount filesystems unless you are root or physically present so they don't seem like major concerns although should be fixed.
- snvzz 11y ago> The correct response is to stop writing to the filesystem. Stop writing AND READING, as what's read can be corrupted and yet written or used elsewhere.
- cyphar 11y ago> They mean BUG as in it crashes the kernel. I know what BUG means. There's a reason it exists: to make sure that code in an invalid state doesn't do something really dangerous. assert() is very useful.
- casas 11y agoIt should be noted that we've hit that BUG() assertion on ext4 using the mount option errors=remount-ro - it should just not be possible to trigger an invalid state causing your kernel to Oops when you've configured it like this. See Vegard's discussion with Theodore Ts'o about this: http://marc.info/?l=linux-ext4&m=144898400422842&w=2 http://marc.info/?l=linux-ext4&m=144898400422842&w=2
- blumentopf 11y agoI'm awed by your work but this is really an abomination: "Unfortunately, company policy prohibits me from sharing the actual code." (http://marc.info/?l=linux-ext4&m=145007745502639&w=2 http://marc.info/?l=linux-ext4&m=145007745502639&w=2)
- SEJeff 11y agoThis was true before the advent of mount namespaces, but is now incorrect: See namespace(7) or something like: http://stackoverflow.com/questions/22889241/linux-understanding-the-mount-namespace-clone-clone-newns-flag http://www.ibm.com/developerworks/library/l-mount-namespaces/
- stevekemp 11y ago> Fuzzing is an incredibly useful technique for finding bugs in a codebase Very much so. Even really common code has issues found via fuzzing on a regular basis. In the past six months I've reported NULL pointer deferences printing fingerprints of SSH keys, segfaults in the GNU awk parser, and most recently segfaults when parsing HTML files with w3m. Most of the time setting up fuzzing is pretty simple, but even updating programs to read from STDIN rather than sockets is usually possible if you're careful and patient. The hardest part is waiting for the damn things to run. Right now I've had a fuzzing session going against the text-based browser lynx for 4 days, and still counting. (Specifically looking to see if it can be crashed when converting HTML to text, as is often done in mutt, etc, via 'lynx -dump').
- masklinn 11y ago> The hardest part is waiting for the damn things to run. Would it be possible to distribute the fuzzing on a small cluster or some cloud platform thing?
- stevekemp 11y agoIf you wrote your own fuzzer, using a queue to distribute work, then almost certainly. But if you're relying on things like AFL then I think the answer is generally "no".
- besselheim 11y agoThere is some provision for parallelization in afl: https://github.com/mirrorer/afl/blob/master/docs/parallel_fuzzing.txt https://github.com/mirrorer/afl/blob/master/docs/parallel_fu...