linux-kernel - Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

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: <20120516021828.GP22082@ZenIV.linux.org.uk>
Date:	Wed, 16 May 2012 03:18:28 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Eric Paris <eparis@...isplace.org>,
	Mimi Zohar <zohar@...ibm.com>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

On Tue, May 15, 2012 at 05:45:44PM -0700, Linus Torvalds wrote:
> On Tue, May 15, 2012 at 5:42 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > Er... ?Looks like you forgot to actually put the patch in there ;-)
> 
> Oops. Err.. I meant to do that. Right. To check that you're awake.

Frankly, I would split it in two - one introducing security_mmap_addr()
and converting the callers, and another doing the rest of it.

Said that, I'm not sure I like the resulting picture.

1) caller in __bprm_mm_init() is simply ridiculous - note that
arguments are bleeding *constants*, so it might very well have
been a BUG_ON().  If it fails, you'll have every execve() fail.

2) get_unmapped_area() probably ought to grow such a caller and
I really suspect that it would've killed quite a few of them.

3) expand_downwards() seems to be missing the basic sanity checks on the
validity of VMA range (arch_mmap_check(), that is).  itanic opencodes
the equivalent before calling expand_stack(); arm and mn10300 do not
bother, which might or might not be legitimate - depends on whether
one can get a fault in the first page *and* reach the check_stack:
in e.g. arm __do_page_fault().  Which just might be possible, if attacker
maps something just above said first page with MAP_GROWSDOWN and
tries to write at very small address - IIRC, the first page on arm
contains the stuff that shouldn't be world-writable...  s390 doesn't
care and I'm not sure about sparc32/sparc64 - it looks like that shouldn't
be possible to hit, but...

4) i810_dma.c ought to be switched to vm_mmap() - as discussed in that
thread back then, magical mystery wank with ->f_op reassignments does
not rely on ->mmap_sem for protection and thus can be taken out of
under ->mmap_sem.
--
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/