Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 5 Jul 2014 23:35:37 +0400
From: Solar Designer <>
Subject: Re: CVE-2014-4699: Linux ptrace bug

Andy, all -

On Sat, Jul 05, 2014 at 10:25:47PM +0400, Solar Designer wrote:
> "x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX (CVE-2014-4699)"
> "CVE-2014-4699 Kernel: x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX"

BTW, I'm not convinced it's such a good idea to allow setting RIP to
exactly TASK_SIZE_MAX just because user code could run to that address
(this was Andy's rationale).  Imagine that TASK_SIZE_MAX is ever set
such that it's the very first non-canonical address.  If user code
simply runs to that address, it gets a user mode fault.  However, if the
kernel tries to set user RIP to that address via SYSRET, it'll get #GP
while still in kernel mode - exactly the problem we're trying to fix.

So when fixing the problem in this way, or when including this as a
hardening measure along with forcing the IRET path as well, I'd prefer
to allow only "< TASK_SIZE_MAX", not "<= TASK_SIZE_MAX".

I think currently TASK_SIZE_MAX is below the first non-canonical
address, so we're fine, but there's little reason to take the risk of
possible (valid) future changes to TASK_SIZE_MAX.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.