Hm, is the use of the preeny library really necessary to get nginx reading from stdin? Couldn't you just 'cat' your fuzzed input files to 'nc' which then connects to the socket nginx is listening to?
Given that this specific form of fuzzing - basically non-directed randomization of inputs (it is pattern based to an extent, but...) performance matters. You want to cover a good portion of a huge surface. Performance tweaks add up in this case.
How many bugs will mucking with intercepting syscalls introduce? More importantly, how many bugs will be obscured since the tool is running Nginx in a decidedly non-standard and complex way?
Good questions - but in the overall workflow, these can be easily found by first running the fuzzing and getting a list of problematic inputs, and second, trying those inputs in a directed way against the unmodified version of nginx provides a nice filter.
As for the obscuring of other bugs - sure, this is always a problem with any form of testing. The goal with this or any tool isn't to find all bugs, its to help find a class of bugs. Other forms of testing will find other bugs. This is why unit tests are valuable, but don't obviate the need for integration and functional testing for example.