Functions like __file_maxbytes and __file_filename make too many assumptions about their arguments. For example, the former only uses deref() for one link in the pointer chain, whereas it really needs it for all steps (in case the intermediate pointers are corrupted). The latter needs to use a protected string-copy, not just a nullness test. This whole tapset should be reviewed for similar optimism.
BTW, adding this to src/HACKING: Embedded-C code should avoid making references to the runtime or - other code possibly generated by the translator. + other code possibly generated by the translator. Embedded-C code that + dereferences pointers should use deref() type functions to check each + individual operation if there exists a possibility that the function may + be called with invalid pointers or pointer chains.
With the resolution of bug #3079, I'm migrating the tapsets to use the kread/kwrite macros. I'll take this bug and audit the tapsets to make sure we're protecting all unknown-pointer dereferences.
The kread migration is finished. There's still an issue with the way bdevname is called (marked with FIXME), but the rest of the code is protected. I left the explicit NULL checks in, because I didn't want to change the functionality of the tapset. Thus it still needs an audit to determine whether those NULL checks are appropriate. In cases where NULL is expected and permitted, leave it as-is, but if NULL should be an error just let the kread catch it.