[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAObL_7Hkuoz12CkEfMwpwPqjAxRqEWNMYw8QSNL+Zs6geMEUfw@mail.gmail.com>
Date: Wed, 1 Apr 2015 14:51:29 -0700
From: Andrew Lutomirski <luto@...nel.org>
To: oss-security@...ts.openwall.com
Subject: CVE Request: Linux mishandles int80 fork from 64-bit tasks
On unpatched x86_64 Linux with 32-bit emulation enabled, calling
fork(2) or close(2) using int $0x80 in a 64-bit task could return back
to user space in the new task using ret_from_sys_call. That's
inappropriate for an int80 entry, and, if nothing else forced a
slow-path syscall return, the kernel would execute SYSRETL.
That would likely break the calling process, since it would
incorrectly return in long mode (i.e. CS would have the wrong value).
This particular failure has no security implications.
There's another problem, though: setup_thread_stack would propagate
TS_COMPAT (i.e. the indication that the task is in a 32-bit syscall)
to the child, and nothing would clear that bit. This violates a
general invariant that tasks executing in user mode never have
TS_COMPAT set.
The user task could then do a normal 64-bit syscall, and
is_compat_task() would incorrectly return true. I don't see any
direct way to escalate privileges as a result, but Ingo Molnar pointed
out that this affects syscall_get_arch. As a result, both seccomp and
audit could misinterpret the offending syscall, with possibly
dangerous results depending on configuration.
I suspect that this could be used to break out of certain seccomp
sandboxes on kernels older than 3.16.
The upstream fix is here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=956421fbb74c3a6261903f3836c0740187cf038b
--Andy
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.
