Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 Apr 2015 14:51:29 -0700
From: Andrew Lutomirski <>
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

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:


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.