fstat triggered INVARIANTS panic in memrw()

[Alan Cox]

On Tue, Jan 18, 2005 at 06:46:57PM -0800, Kris Kennaway wrote:
> On Tue, Jan 18, 2005 at 02:31:53PM -0600, Alan Cox wrote:
> 
> > > An interesting datapoint is that none of the non-i386 package machines
> > > have hit this problem, but the i386 machines can't stay up for more
> > > than a few minutes under load (which translates to only a few fstat
> > > invocations).
> > 
> > The field f_offset is 64 bits wide.  If this were a race between use
> > and deallocation of the file structure within the kernel, then I would
> > expect f_offset's value to be 0xdeadc0dedeadc0de, not
> > 0x00000000deadc0de.  More likely than not, the 0xdeadc0de is being
> > passed in from user level.  The i386 kernel is just not handling it
> > gracefully.  
> 
> Shouldn't this at least be hitting the check in memrw():
> 
>                         if (!kernacc((caddr_t)(int)uio->uio_offset, c,
>                             uio->uio_rw == UIO_READ ?
>                             VM_PROT_READ : VM_PROT_WRITE))
>                                 return (EFAULT);
>                         error = uiomove((caddr_t)(int)uio->uio_offset, (int)c, uio);
> 
> (kgdb) print uio->uio_offset
> $2 = 3735929054
> (kgdb) print uio->uio_rw
> $3 = UIO_READ
> (kgdb) print c
> $4 = 2058814332

Yes, it should.  :-)  The problem is two-fold.  First, kernacc()
unlike useracc() doesn't check for address wrap, i.e., end < start.
Presumably the author of kernacc() assumed that kernel code would
never call kernacc() with such dubious arguments.  Second,
vm_map_check_protection() returns "success" whenever address wrap
occurs. 

Alan