CHROMIUM: mwifiex: fix a crash in extended scan event processing

[113.967694] Unable to handle kernel NULL pointer dereference
               at virtual address 00000020
............
[113.967859] PC is at mwifiex_update_rxreor_flags+0xfc/0x430
............
[113.968110] mwifiex_update_rxreor_flags+0xfc/0x430
[113.968129] mwifiex_handle_event_ext_scan_report+0x1e4/0x21c
[113.968148] mwifiex_process_sta_event+0x410/0x508
[113.968165] mwifiex_process_event+0x184/0x1e0
[113.968181] mwifiex_main_process+0x220/0x48c
[113.968197] mwifiex_sdio_interrupt+0xc8/0x1cc
[113.968210] sdio_irq_thread+0x11c/0x290

In case of legacy scan, adapter->curr_cmd is guranteed to be
non-NULL in check_next_scan_cmd. This may not be case in
extended scan where scan command response would come earlier and
set curr_cmd to NULL. Extended scan event comes later and while
trying to complete IOCTL for scan, driver would crash in
dereferencing adapter->curr_cmd->wait_q_enabled.

Avoid this by completing IOCTL in case of legacy scans only.
Internal scan would be completed while handling extended scan
command response.

Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:28835
TEST="while true; do echo scanning; iw mlan0 scan | grep SSID;
done" overnight test and suspend_stress_test 10000 times.

Change-Id: I0fb940d724346d2f4a52af3bcb431c9108cf1503
Reviewed-on: https://chromium-review.googlesource.com/201378
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
(cherry picked from commit 265e163a7e975cac213d4b15d8af406ffd2068c2)
Reviewed-on: https://chromium-review.googlesource.com/202143
Commit-Queue: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
UPSTREAM: 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>

BUG=chromium:377392
TEST=nyan build & boot

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202664
Reviewed-by: Will Drewry <wad@chromium.org>

(cherry picked from ToT commit 04bee4e6d1d6eeb6523eb7c0981c00edf2b4af14)
Signed-off-by: Kees Cook <keescook@chromium.org>

Change-Id: If1721711a2698551c054d5fad6b7c04581f71b4b
Reviewed-on: https://chromium-review.googlesource.com/202604
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
UPSTREAM: 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>

BUG=chromium:377392
TEST=nyan build & boot

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202665
Reviewed-by: Will Drewry <wad@chromium.org>

(cherry picked from ToT commit bfc19d26e4fa90045c0084cdc130d185f972e84a)
Signed-off-by: Kees Cook <keescook@chromium.org>

Change-Id: I28e9b3dba6a5df56f2e63aec5bcc7d47e456f345
Reviewed-on: https://chromium-review.googlesource.com/202605
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
UPSTREAM: 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

BUG=chromium:377392
TEST=nyan build & boot

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202666
Reviewed-by: Will Drewry <wad@chromium.org>

(cherry picked from commit ToT 03a29d580571d67a51c83db5eeac30e333cb1c01)
Signed-off-by: Kees Cook <keescook@chromium.org>

Change-Id: Ie11adb7056e855a23b8d2e2587c509c3a200eba0
Reviewed-on: https://chromium-review.googlesource.com/202606
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
UPSTREAM: 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

BUG=chromium:377392
TEST=nyan build & boot

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202667
Reviewed-by: Will Drewry <wad@chromium.org>

(cherry picked from commit ToT 08f7ef8275377c3a28ab729f96853a938be47455)
Signed-off-by: Kees Cook <keescook@chromium.org>

Change-Id: I01552cd555bcbead9cea3024b382cce3c831b903
Reviewed-on: https://chromium-review.googlesource.com/202607
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
CHROMIUM: gsc: Do not change the image size to smaller than the request.

Use the requested size as the minimum bound, unless it's less than the
required hardware minimum. The bound align function will align to the
closest value but we do not want to adjust below the requested size.

Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org>

BUG=chromium:377632
TEST=webrtc call and VEA unittest.

Change-Id: I11957d2df478758451a9291b82e8ab69e902ced6
Reviewed-on: https://chromium-review.googlesource.com/202107
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: Wu-Cheng Li <wuchengli@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
(cherry picked from commit 88a7e270ab53ebee0cd0bdcad28ff2a95ab9e5de)
Reviewed-on: https://chromium-review.googlesource.com/202893
Tested-by: Pawel Osciak <posciak@chromium.org>