linux-kernel - Re: sendmmsg: put_user vs __put

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: <20120405.210113.1089032911004787990.davem@davemloft.net>
Date:	Thu, 05 Apr 2012 21:01:13 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	luto@....edu
Cc:	drepper@...il.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: sendmmsg: put_user vs __put_user

From: Andy Lutomirski <luto@....edu>
Date: Thu, 05 Apr 2012 17:14:25 -0700

> On 03/30/2012 05:51 PM, David Miller wrote:
>> From: Ulrich Drepper <drepper@...il.com>
>> Date: Fri, 30 Mar 2012 09:36:11 -0400
>> 
>>> Shouldn't the compat code in the sendmmsg implementation use the same
>>> code as the normal code?  In which case you probably want something
>>> like this:
>> 
>> Compat processes are not able to generate virtual addresses anywhere
>> near the range where the kernel resides, so the address range
>> verification done by put_user() is completely superfluous and
>> therefore not necessary.  The normal exception handling done by the
>> access is completely sufficient.
> 
> I disagree.  The following exploit causes a bogus page fault to a kernel
> address.  I think this isn't exploitable right now on x86-64 because the
> page fault handler fixes it up, but I wouldn't be surprised if this
> crashes or at least warns on some architecture.  (Actually trashing
> kernel memory is probably impossible with this on x86-64 chips because
> this can only overrun user space by four bytes, and there's a giant gap
> of impossible addresses above user space in x86-64.

I can guarentee this doesn't do anything on sparc64 either because
userspace is completely segregated from kernel space in a way that
every single foo_user() call cannot access kernel space no matter
what address it can trick into being passed there.

I still really don't see an issue with this, sorry.
--
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/