https://bugzilla.redhat.com/show_bug.cgi?id=1055771 Bug ID: 1055771 Summary: Review Request: trinity - System call fuzz tester Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@xxxxxxxxxxxxxxxxx Reporter: loganjerry@xxxxxxxxx QA Contact: extras-qa@xxxxxxxxxxxxxxxxx CC: package-review@xxxxxxxxxxxxxxxxxxxxxxx Spec URL: http://jjames.fedorapeople.org/trinity/trinity.spec SRPM URL: http://jjames.fedorapeople.org/trinity/trinity-1.3-1.fc21.src.rpm Fedora Account System Username: jjames Description: Trinity makes syscalls at random, with random arguments. Where Trinity differs from other fuzz testers is that the arguments it passes are not purely random. We found some bugs in the past by just passing random values, but once the really dumb bugs were found, these dumb fuzzers would just run and run. The problem was if a syscall took for example a file descriptor as an argument, one of the first things it would try to do was validate that fd. Being garbage, the kernel would just reject it as -EINVAL of course. So on startup, Trinity creates a list of file descriptors, by opening pipes, scanning sysfs, procfs, /dev, and creates a bunch of sockets using random network protocols. Then when a syscall needs an fd, it gets passed one of these at random. File descriptors aren't the only thing Trinity knows about. Every syscall has its arguments annotated, and where possible it tries to provide something at least semi-sensible. "Length" arguments for example get passed one of a whole bunch of potentially interesting values. (Powers of 2 +/-1 are a good choice for triggering off-by-one bugs it seems). Trinity also shares those file descriptors between multiple threads, which causes havoc sometimes. If a child process successfully creates an mmap, the pointer is stored, and fed to subsequent syscalls, sometimes with hilarious results. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review