linux-kernel - Re: vfs: oops on open_by_handle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121008034955.GP2616@ZenIV.linux.org.uk>
Date:	Mon, 8 Oct 2012 04:49:55 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Sasha Levin <levinsasha928@...il.com>,
	Dave Jones <davej@...hat.com>, Sage Weil <sage@...tank.com>,
	Steven Whitehouse <swhiteho@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: vfs: oops on open_by_handle_at() in linux-next

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/