futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

If uaddr == uaddr2, then we have broken the rule of only requeueing
from a non-pi futex to a pi futex with this call. If we attempt this,
then dangling pointers may be left for rt_waiter resulting in an
exploitable condition.

This change brings futex_requeue() into line with
futex_wait_requeue_pi() which performs the same check as per commit
6f7b0a2a5 (futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi())

[ tglx: Compare the resulting keys as well, as uaddrs might be
  	different depending on the mapping ]

Fixes CVE-2014-3153.

Reported-by: Pinkie Pie
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Git-commit: 5b3bbe42f5874081123fa3aa4dd85d5e5c806f54
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
futex: Validate atomic acquisition in futex_lock_pi_atomic()

We need to protect the atomic acquisition in the kernel against rogue
user space which sets the user space futex to 0, so the kernel side
acquisition succeeds while there is existing state in the kernel
associated to the real owner.

Verify whether the futex has waiters associated with kernel state. If
it has, return -EINVAL. The state is corrupted already, so no point in
cleaning it up. Subsequent calls will fail as well. Not our problem.

[ tglx: Use futex_top_waiter() and explain why we do not need to try
  	restoring the already corrupted user space state. ]

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Git-commit: 550c7910f0e2fd4f130fec2f17541f3614fdfaf9
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
futex: Always cleanup owner tid in unlock_pi

If the owner died bit is set at futex_unlock_pi, we currently do not
cleanup the user space futex. So the owner TID of the current owner
(the unlocker) persists. That's observable inconsistant state,
especially when the ownership of the pi state got transferred.

Clean it up unconditionally.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
Git-commit: a2ec8e3dcdc6c93f574a0e22039b791cc5e14fa6
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
futex: Make lookup_pi_state more robust

The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex. We can get into the kernel
even if the TID value is 0, because either there is a stale waiters
bit or the owner died bit is set or we are called from the requeue_pi
path or from user space just for fun.

The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address. This can lead to state leakage and worse under some
circumstances.

Handle the cases explicit:

     Waiter | pi_state | pi->owner | uTID      | uODIED | ?

[1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
[2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

[3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

[4]  Found  | Found    | NULL      | 0         | 1      | Valid
[5]  Found  | Found    | NULL      | >0        | 1      | Invalid

[6]  Found  | Found    | task      | 0         | 1      | Valid

[7]  Found  | Found    | NULL      | Any       | 0      | Invalid

[8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
[9]  Found  | Found    | task      | 0         | 0      | Invalid
[10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

[1]  Indicates that the kernel can acquire the futex atomically. We
     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

[2]  Valid, if TID does not belong to a kernel thread. If no matching
     thread is found then it indicates that the owner TID has died.

[3]  Invalid. The waiter is queued on a non PI futex

[4]  Valid state after exit_robust_list(), which sets the user space
     value to FUTEX_WAITERS | FUTEX_OWNER_DIED.

[5]  The user space value got manipulated between exit_robust_list()
     and exit_pi_state_list()

[6]  Valid state after exit_pi_state_list() which sets the new owner in
     the pi_state but cannot access the user space value.

[7]  pi_state->owner can only be NULL when the OWNER_DIED bit is set.

[8]  Owner and user space value match

[9]  There is no transient state which sets the user space TID to 0
     except exit_robust_list(), but this is indicated by the
     FUTEX_OWNER_DIED bit. See [4]

[10] There is no transient state which leaves owner and user space
     TID out of sync.

Backport to 3.13
  conflicts: kernel/futex.c

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
Git-commit: b50939f89dae691f8da9e0fd22e0eae0db1c0ae4
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
Revert "msm: mdss: During status check for mdp3, only prevent off"

This reverts commit bd61ae8e3559a92491457c4a732e3340095d0c28.
Revert "msm: mdss: use ov_lock only for command mode status check"

This reverts commit 6b8cc36d2963741890b5b953ce36439d64e315a3.
Revert "Revert "msm: mdss: Check extra mmb allocated to a pipe""

This reverts commit 2c668d4b0c14b4c725966b1e0f6f5cd1162ca6b0.
Revert "msm: mdss: Allow displays to go to HS mode post-init"

This reverts commit e31c39a6170b202eef1e798858c10b74f692df81.
Revert "msm: mdss: Add sysfs method to enable/disable TE"

This reverts commit cd31db2bbd272b8c4fb42504f19bfee411108edc.
Revert "msm: mdss: Add sysfs method to retrieve frame counter"

This reverts commit 942e60cb65aeccf023d7cf0f25c4d2ce7c11f8a0.
Revert "msm: mdss: Log bootloader display auto detect status at boot"

This reverts commit bde662ae452494af47592d69db9cfdde96be35ac.
Revert "msm: mdss: Initialize mdp3 dma configs for continuous splash"

This reverts commit acf2535e03c627fd274a45b3d2ae1e1de4081934.
Revert "msm: mdss: init timeout framework after ctl is setup"

This reverts commit 1f642fd34c6d2198014bfaa56a4e32f01d75e130.
Revert "msm: mdss: Workaround to exit an unexpected ESD workqueue"

This reverts commit 5bea864a9aa87da40fcda388321589f72e237155.
Revert "msm: mdss: only dump a vsync timeout after vsync enabled"

This reverts commit defdf183077d750a596428775104914b1cb2519c.
Revert "msm: mdss: fix display corruption on 720p panel"

This reverts commit bca5bd8f08ac0c57a31458b46a31ea2c7700061e.
Revert "msm: mdss: Use Qcom's ESD detection/recovery instead."

This reverts commit ccba2317547e05cee279b2323a3bb4a6d79a52f3.
Revert "mdss: display: fix compile error when not using timeout"

This reverts commit 60fb91307eaa7daa6a4d4c126185e967e89ffa8a.
Revert "msm: mdss: Change mdss_dsi_status interval to 8 seconds"

This reverts commit 6d89786eed4fd280fb50891291519d7f57acb44c.
Revert "msm: mdss: Make mdss_dsi_status able to be disabled or enabled."

This reverts commit d5ea8dee8dcf8322a770da70f4544b9b413574eb.