On Sun, Oct 07, 2012 at 08:32:51PM -0700, Hugh Dickins wrote: > Thank you, Sasha: this should fix it, and similar in other FSes. > > > [PATCH] tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking > > Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(), > u64 inum = fid->raw[2]; > which is unhelpfully reported as at the end of shmem_alloc_inode(): > > BUG: unable to handle kernel paging request at ffff880061cd3000 > IP: [<ffffffff812190d0>] shmem_alloc_inode+0x40/0x40 > Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > Call Trace: > [<ffffffff81488649>] ? exportfs_decode_fh+0x79/0x2d0 > [<ffffffff812d77c3>] do_handle_open+0x163/0x2c0 > [<ffffffff812d792c>] sys_open_by_handle_at+0xc/0x10 > [<ffffffff83a5f3f8>] tracesys+0xe1/0xe6 > > Right, tmpfs is being stupid to access fid->raw[2] before validating that > fh_len includes it: the buffer kmalloc'ed by do_sys_name_to_handle() may > fall at the end of a page, and the next page not be present. > > But some other filesystems (ceph, gfs2, isofs, reiserfs, xfs) are being > careless about fh_len too, in fh_to_dentry() and/or fh_to_parent(), and > could oops in the same way: add the missing fh_len checks to those.
TBH, I really don't like it. How about putting minimal acceptable fhandle length into export_operations instead? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
