Now that the previous commit made it possible to do the personality
setting at the point of no return, we do just that for ELF binaries.
And suddenly all the reasons for that insane TIF_ABI_PENDING bit go
away, and we can just make SET_PERSONALITY() just do the obvious thing
for a 32-bit compat process.
Everything becomes much more straightforward this way.
Signed-off-by: H. Peter Anvin <email address hidden>
Cc: <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry-picked from commit 05d43ed8a89c159ff641d472f970e3f1baa66318 upstream)
Signed-off-by: Surbhi Palande <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
6cf69a2...
by
Linus Torvalds <email address hidden>
Fix 'flush_old_exec()/setup_new_exec()' split
CVE-2010-0307
Commit 221af7f87b9 ("Split 'flush_old_exec' into two functions") split
the function at the point of no return - ie right where there were no
more error cases to check. That made sense from a technical standpoint,
but when we then also combined it with the actual personality setting
going in between flush_old_exec() and setup_new_exec(), it needs to be a
bit more careful.
In particular, we need to make sure that we really flush the old
personality bits in the 'flush' stage, rather than later in the 'setup'
stage, since otherwise we might be flushing the _new_ personality state
that we're just setting up.
So this moves the flags and personality flushing (and 'flush_thread()',
which is the arch-specific function that generally resets lazy FP state
etc) of the old process into flush_old_exec(), so that it doesn't affect
any state that execve() is setting up for the new process environment.
This was reported by Michal Simek as breaking his Microblaze qemu
environment.
Reported-and-tested-by: Michal Simek <email address hidden>
Cc: Peter Anvin <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry-picked from commit 7ab02af428c2d312c0cf8fb0b01cc1eb21131a3d upstream)
Signed-off-by: Surbhi Palande <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
28b9547...
by
Linus Torvalds <email address hidden>
Split 'flush_old_exec' into two functions
CVE-2010-0307
'flush_old_exec()' is the point of no return when doing an execve(), and
it is pretty badly misnamed. It doesn't just flush the old executable
environment, it also starts up the new one.
Which is very inconvenient for things like setting up the new
personality, because we want the new personality to affect the starting
of the new environment, but at the same time we do _not_ want the new
personality to take effect if flushing the old one fails.
As a result, the x86-64 '32-bit' personality is actually done using this
insane "I'm going to change the ABI, but I haven't done it yet" bit
(TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
personality, but just the "pending" bit, so that "flush_thread()" can do
the actual personality magic.
This patch in no way changes any of that insanity, but it does split the
'flush_old_exec()' function up into a preparatory part that can fail
(still called flush_old_exec()), and a new part that will actually set
up the new exec environment (setup_new_exec()). All callers are changed
to trivially comply with the new world order.
Signed-off-by: H. Peter Anvin <email address hidden>
Cc: <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry-picked from commit 221af7f87b97431e3ee21ce4b0e77d5411cf1549 upstream)
Signed-off-by: Surbhi Palande <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
Currently we are not including randomized stack size when calculating
mmap_base address in arch_pick_mmap_layout for topdown case. This might
cause that mmap_base starts in the stack reserved area because stack is
randomized by 1GB for 64b (8MB for 32b) and the minimum gap is 128MB.
If the stack really grows down to mmap_base then we can get silent mmap
region overwrite by the stack values.
Let's include maximum stack randomization size into MIN_GAP which is
used as the low bound for the gap in mmap.
Signed-off-by: Michal Hocko <email address hidden>
LKML-Reference: <email address hidden>
Acked-by: Jiri Kosina <email address hidden>
Signed-off-by: H. Peter Anvin <email address hidden>
Cc: Stable Team <email address hidden>
(cherry-picked from 80938332d8cf652f6b16e0788cf0ca136befe0b5 upstream)
Signed-off-by: Surbhi Palande <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
If the owner of a PI futex dies we fix up the pi_state and set
pi_state->owner to NULL. When a malicious or just sloppy programmed
user space application sets the futex value to 0 e.g. by calling
pthread_mutex_init(), then the futex can be acquired again. A new
waiter manages to enqueue itself on the pi_state w/o damage, but on
unlock the kernel dereferences pi_state->owner and oopses.
Prevent this by checking pi_state->owner in the unlock path. If
pi_state->owner is not current we know that user space manipulated the
futex value. Ignore the mess and return -EINVAL.
This catches the above case and also the case where a task hijacks the
futex by setting the tid value and then tries to unlock it.
Reported-by: Jermome Marchand <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Acked-by: Darren Hart <email address hidden>
Acked-by: Peter Zijlstra <email address hidden>
Cc: <email address hidden>
(cherry-picked from 51246bfd189064079c54421507236fd2723b18f3 upstream)
Signed-off-by: Surbhi Palande <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
