a third bug in musl clone()

[John Reiser <jreiser@bitwagon.com>]

In addition to the bugs in __clone for i386 with %gs and stack alignment
in the new thread, there is a third bug in musl's implementation of clone().
clone() takes optional arguments that need not be present,
yet musl/src/linux/clone.c fetches them anyway.  This can cause SIGSEGV.

===== musl/src/linux/clone.c excerpts
int clone(int (*func)(void *), void *stack, int flags, void *arg, ...)
{
    [[snip]]
         va_start(ap, arg);
         ptid = va_arg(ap, pid_t *);
         tls  = va_arg(ap, void *);
         ctid = va_arg(ap, pid_t *);
         va_end(ap);

         return __syscall_ret(__clone(func, stack, flags, arg, ptid, tls, ctid));
}
=====
The presence of ptid, tls, and ctid is indicated by bits in 'flags':
CLONE_PARENT_SETTID, CLONE_SETTLS, CLONE_CHILD_SETTID/CLONE_CHILD_CLEARTID.
If none of those bits are set, then it could be that none of the variable
arguments are present; therefore none of them should be fetched, and 0 (NULL)
should be passed to __clone() for each of ptid, tls, ctid.
[The meaning is unclear if any omitted argument is followed by an argument
that is flagged as present.  Should the implementation call the corresponding
va_arg(), or skip over it?]

How SIGSEGV can be generated: It is valid for &arg to be the address of
the last word on a hardware page: 0x...ffc on a 32-bit CPU with 4KiB pages,
with the following page unmapped.  &func would be 16-byte aligned at 0x...ff0.
Any one of the va_arg() calls would attempt to fetch from the next
page at address 0x...000 or greater, which will generate SIGSEGV.

If the implementer of clone() actually thought about this then it
is MANDATORY to insert a code comment about the situation.  Such as:
    /* Always fetch ptid,tls,ctid even though the official standard
     * says that they are va_arg.  The standard says that only
     * to allow compilation of [old] calls that omit un-flagged
     * trailing arguments.  In practice it is highly unreasonable
     * to require conditional fetching; even the meaning is unclear.
     * In the extremely unlikely case that &arg is near a "hole"
     * in the address space, then we will suffer SIGSEGV.
     */

--