linux-kernel - Re: fs: gpf in simple

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] [day] [month] [year] [list]

Message-ID: <5332EBA1.4080701@oracle.com>
Date:	Wed, 26 Mar 2014 11:00:49 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Dave Jones <davej@...hat.com>, Jan Kara <jack@...e.cz>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: fs: gpf in simple_setattr

On 03/26/2014 01:53 AM, Dave Jones wrote:
> On Tue, Mar 25, 2014 at 10:12:29PM +0100, Jan Kara wrote:
>
>   > This fixes an oops triggered by trinity when it tried mounting
>   > anon_inodefs which overwrote anon_inode_inode pointer while other CPU
>   > has been in anon_inode_getfile() between ihold() and d_instantiate().
>   > Thus effectively creating dentry pointing to an inode without holding a
>   > reference to it.
>
> <raises eyebrows>
>
> Sasha, do you have changes to trinity's syscall/mount.c ?
> It's kind of miraculous we managed to get the type arg right
> there, because right now we're just passing a random address as an arg.
> The only way that could work is if we randomly managed to do an allocation,
> and then a seek & read from /proc/filesystems to that buffer.  If you're
> lucky enough to get all those conditions right from rand() calls, you should
> probably give up on kernel hacking and buy some powerball tickets.
>
> We should add some code to make that only return strings from /proc/filesystems,
> which makes me wonder if you already did that..

Almost :)

I'm mounting every filesystem under /prov/filesystems into trinity's victims path
before trinity starts, so it gets to fuzz every filesystem known to the kernel.

For nodev filesystems it just mounts then and for nodev ones it will try to
mkfs.$fs a block device and mount that.

So basically I'm not surprised by the explanation for that bug or that trinity
has triggered it.


Thanks,
Sasha


--
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/