4 ms·
> Someone else then comes up with a mad but very real mainstream program that relies upon the system call succeeding. Mandatory xkcd reference https://xkcd.co
by petemir 3y ago
> Someone else then comes up with a mad but very real mainstream program that relies upon the system call succeeding.
Mandatory xkcd reference https://xkcd.com/1172/ https://xkcd.com/1172/
- JdeBP 3y agoIn this case, it was a kernel filesystem driver test suite, and the test suite isn't in fact relying at all upon argv being a zero-length array. It's not part of any workflow. Indeed, the test suite is, rather, this very bug waiting to happen. Still. Two years later. https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/src/vfs/vfstest.c#n503 https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/... Easily solved by: static char *argv[] = { FILE1, NULL, }; The xfs test program invoked by the execve() is calling getopt_long_only() passing the zero argc and a zero-length argv that execve() was given. It is quite ironic that that test program is thus exceeding the argument vector bounds and going off into some adjacent part of memory, because one of the first things that getopt_long_only() does is: optind = 1; /* Don't scan ARGV[0], the program name. */