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? */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 15 2002 - 22:00:31 EST