Re: [BK][PATCH] ReiserFS CPU and memory bandwidth efficient large writes

[Andrew Morton <akpm@digeo.com>]

Oleg Drokin wrote:
> 
> > > +   if ( from != 0 ) {/* First page needs to be partially zeroed */
> > > +       char *kaddr = kmap_atomic(prepared_pages[0], KM_USER0);
> > > +       memset(kaddr, 0, from);
> > > +       kunmap_atomic( kaddr, KM_USER0);
> > > +       SetPageUptodate(prepared_pages[0]);
> > > +   }
> > > +   if ( to != PAGE_CACHE_SIZE ) { /* Last page needs to be partially zeroed */
> > > +       char *kaddr = kmap_atomic(prepared_pages[num_pages-1], KM_USER0);
> > > +       memset(kaddr+to, 0, PAGE_CACHE_SIZE - to);
> > > +       kunmap_atomic( kaddr, KM_USER0);
> > > +       SetPageUptodate(prepared_pages[num_pages-1]);
> > > +   }
> > This seems wrong.  This could be a newly-allocated pagecache page.  It is not
> > yet fully uptodate.  If (say) the subsequent copy_from_user gets a fault then
> > it appears that this now-uptodate pagecache page will leak uninitialised stuff?
> 
> No, I do not see it. Even if we have somebody already mmapped this part of file,
> and he got enough of luck that subsequent copy_from_user gets a fault and then
> this someone gets to CPU and tries to access the page, the SIGBUS should happen
> because of access to mmaped area beyond end of file as we have not yet updated
> the file size note that we have this check before this code you pointed out:
>     if ( (pos & ~(PAGE_CACHE_SIZE - 1)) > inode->i_size ) {
> 

It is not related to mmap.  The exploit would be to pass a partially
(or fully?) invalid (address, length) pair into the write() system call.

Something like:

	fd = creat(...);
	write(fd, 0, 4095);		/* efault, instantiate 0'th page */
	lseek(fd, 4096, SEEK_SET);
	write(fd, "", 1);		/* place the 0'th page inside i_size */
	lseek(fd, 0, SEEK_SET);
	read(fd, my_buffer, 4095);	/* now what do we have? */