Re: fstat triggered INVARIANTS panic in memrw()

I've looked a little deeper into Kris's fstat panic.
Turns out there are bugs in three places.

(1) fstat(1) sometimes calls kvm_read() with a ridiculously out-of-
bounds value for nbytes.  In fstat.c, dofiles() gets a struct filedesc
via kvm_read(), and sometimes the value for fd_lastfile (the high-
water mark for file descriptors) is garbage.  This value (times
sizeof(struct file *)) is then passed to the next kvm_read() as the
number of bytes to read.  A classic case where you need to be
suspicious of the data from kvm_read() in a running kernel.

This same problem was reported a year ago in PR i386/62699.

The best you can do is pick some bounds and add a sanity check to
fd_lastfile.  I sent a patch to PR 62699.  I don't know if fstat(1)
has a regular maintainer, but there have been a couple commits over
the past year or two.  If someone in the area could review the patch
and commit it (it's short).

(2) kvm_read() and kmem(4) don't check for address wrap.  This shows
up in kernacc() in vm_glue.c and then in vm_map_check_protection() in
vm_map.c.  I was able to induce the same address wrap in kernacc()
without using fstat(1) in two ways.  One is with kvm_open(),
kvm_getprocs() and kvm_read(), the other is with open("/dev/kmem"),
lseek() and read().  In both cases, a large enough value for number of
bytes will induce address wrap in kernacc().

I haven't looked into this too deeply.  I know the address wrap
happens, but I don't know the best place to fix it.  Maybe someone
more familiar with kvm(3) and kmem(4) could take a look.

(3) kernacc() in vm_glue.c doesn't check for address wrap.  Alan
recently committed a patch for kernacc(), so this is now fixed.

--Mark