On 05.06.2018 18:14, Valery Ushakov wrote: > Kamil Rytarowski <n54%gmx.com@localhost> wrote: > >> We've faced a problem with sanitizing part of the NetBSD userland, as we >> need to use helper functions to make sanitization possible in some >> narrow cases that aren't clear for sanitizers. >> >> The current problem is the usage of callback functions defined in >> programs and executed from the internals of libc. > [...] >> Once a callback function is executed from the internals of libc, a >> sanitized program does not know whether the arguments passed to it are >> properly initialized. > > Why? What makes calling from libc special? It's probably obvious to > you since you've been workign on this for a while, but most of us have > no clue. > > -uwe > I've applied this approach from "ls" to: "mtree -c" and "find -s" and improved their execution under MSan. (mtree(8) needs more work for some other interceptors) The generic callback scenarios in qsort(3) in modstat(8) happened to be false positive from other bug, please disregard this. I will fix this separately directly in the code of sanitizers. In the fts_open(3) case, there is performed allocation of FTSENT entries inside libc and this buffer is passed to the callback function without prior notifying the user of fts_open(3) about these elements (their address and size of initialized buffer). MSan does not know whether the passed arguments to the arguments of the callback are initialized or not. The shortcoming of a new header is that mtree(8) is a tool program and this new header will be pulled into compat. Sanitizing tools has no point and there might be need in future to track changes in this header.
Attachment:
signature.asc
Description: OpenPGP digital signature