[Valgrind-users] checking the arguments to system calls?

[John R. <jreiser@BitWagon.com>]

Where are the arguments to a system call checked for having defined values?
For instance, open() can take 3 arguments, yet case __NR_open in
coregrind/vg_syscalls.c does no checking regarding arg3.  See testcase below.

If trailing arguments to mmap2() [and/or other syscalls that take many]
are omitted, then shouldn't valgrind complain?

The checking of __NR_select and __NR_newselect is incorrect in 1.9.5:
-----
          if (arg2 != 0)
             SYSCALL_TRACK( pre_mem_read, tst, "newselect(readfds)",
                               arg2, arg1/8 /* __FD_SETSIZE/8 */ );
-----
Every instance of "arg1/8" should be "(7+arg1)/8" instead.  It is very
common for code that uses select() to "know" exactly the maximum fd in a set,
and to specify only  1+max_fd  as arg1.  So if max_fd is 3 then arg1 is 4,
and arg1/8 is zero, yet the kernel must (and does) read at least 1 byte
in this case.  In fact, examining the code for get_fd_set() in
linux/include/linux/poll.h leads to the conclusion that "4*((31 + arg1)/32)"
is the byte length that Linux actually uses on x86.  [Try putting an fd_set
high on a page, unaligned, near a page hole.]


-----bug_open.c
#include <stdlib.h>
#include <fcntl.h>
main()
{
         return open("foo", O_CREAT|O_RDWR);
/* Missing 3rd arg [permission bits] to open(), should be diagnosed
    as a read from an allocated-but-unwritten location on stack,
    followed by [an implied, and actual] use of the value by the kernel.
    As compiled by gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
    using "gcc -g" [no -O]:
         0x8048324 <main>:       push   %ebp
         0x8048325 <main+1>:     mov    %esp,%ebp
         0x8048327 <main+3>:     sub    $0x8,%esp
         0x804832a <main+6>:     and    $0xfffffff0,%esp
         0x804832d <main+9>:     mov    $0x0,%eax
         0x8048332 <main+14>:    sub    %eax,%esp
         0x8048334 <main+16>:    sub    $0x8,%esp  # 3rd arg undefined
         0x8048337 <main+19>:    push   $0x42      # 2nd arg (flags)
         0x8048339 <main+21>:    push   $0x80483f4 # 1st arg (name)
         0x804833e <main+26>:    call   0x8048264 <open>
    Similar holes can be observed with gcc < 3.2 by declaring a local
    array whose initial elements are never written.
*/
}
-----

-- 
John Reiser, jreiser@BitWagon.com