futex: Prevent attaching to kernel threads

We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.

Found while analysing the fallout of Dave Jones syscall fuzzer.

We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.

Change-Id: Id43144232efa7c3ae7c630cffa69f55ff83d8fd9
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
futex: Add another early deadlock detection check

Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
  http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com

That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
    - it can detect that issue early
    - it avoids a different and more complex fixup for backing out

If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.

The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.

Change-Id: I038ce8d61ee0d427574939b048035877149a2981
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
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.

Change-Id: I6bfa0943ee54d6331e6faa7779d621f9cf19fe52
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>
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. ]

Change-Id: Ifca31cf91f32a408171a01b8db1e49c14411a776
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>
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.

Change-Id: I8708a8c38c82ac4565634421fce8f916a6da873b
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
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

Change-Id: Ibec82fe154f4ed702332d2d259ec88317b6fede1
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
wlan: Revert back changes setting the gLimRspReqd for stats requests

The link speed is showing as 0 in the display as the function
limProcessNormalHddMsg(pMac, limMsg, false) is being
called with fRspReqd as false for eWNI_SME_STA_STAT_REQ.

Changes are made to revert back freeing the request when fRspReqd
is false in functions __limProcessSmeGetStatisticsRequest,
__limProcessSmeGetRoamRssiRequest and __limProcessSmeStatsRequest.

Change-Id: Ia9b33dd2484976c54f58b3cac1a8a34c36242f8f
CRs-Fixed: 541869
ASoC: msm: Reset the stream open flag after CMD_CLOSE is sent to DSP

In case of gapless playback, driver does not wait for EOS. CMD_CLOSE
for stream one or two can be called from compress driver free before
EOS ACK for stream one is received. This can result in CMD_CLOSE to
be sent for already closed stream. Reset the stream open flag after
CMD_CLOSE is sent to DSP to prevent multiple CMD_CLOSE on same
stream.

Change-Id: Ic186ae37a760a2996ebd7b9b5dc5d5846621ab66
Signed-off-by: Krishnankutty Kolathappilly <kkolat@codeaurora.org>
ASoC: msm: Add PCM support in compress driver

PCM playback support is added to compress driver so that application
can use the single audio hardware device to play both compressed
and PCM audio.

Change-Id: Ie7719be8d7435088a7e4cfb5b817d4557e25e4c5
Signed-off-by: Dhananjay Kumar <dhakumar@codeaurora.org>
ASoC: msm: Add check for NULL pointer and buffer overflow

Changes to add check for NULL pointer before they
get dereferenced and check for buffer overflows
to ensure out of bound indexes of arrays are not
accessed.

CRs-fixed: 628847 628850
Change-Id: I3fcebe07a7f9e7ff480857480fa0df2ada017c69
Signed-off-by: Aravind Kumar <akumark@codeaurora.org>
ASoC: msm: Send endpoint parameters for DDP decoder

DDP decoder requires end point parameters to be configured or
updated based on the input clip configuration or as updated by
the user through set parameter. Add support for the same

Change-Id: I1d331b4be27d67e1da5b3a03cfaff161e5fd1550
Signed-off-by: Subhash Chandra Bose Naripeddy <snariped@codeaurora.org>
ASoC: msm: ensure check before accessing session private data.

The compressed session needs to be active to set volume to dsp.
Ensure the check to see valid session exist before accessing
private data, else results in kernel panic.

The Memory allocation for driver data also needs to be freed
for failure in session open.

CRs-Fixed: 638817
Change-Id: Ifdce543aa55df420960e9eeff0564f18d9410060
Signed-off-by: Asish Bhattacharya <asishb@codeaurora.org>
ASoC: compr: Disable soft-pause for compress playback

Soft-pause (i.e pause ack after a timeout) adversely affects
audio/video sync during pause/resume use cases leading to some
frame drops. Disable this feature for compress playback.

Change-Id: I3ce444dadf1e4b94c1e8d6f017a1c639b082285f
Signed-off-by: Haynes Mathew George <hgeorge@codeaurora.org>
CRs-Fixed: 636328
msm: compr: Use irq{save/restore} version of spinlock

compress driver event handler uses spin_lock/unlock APIs.
It should be sufficient to use the irq{save/restore} versions.

Change-Id: I8f32c6896396a09faa1baf741bd182d8ceb4301a
Signed-off-by: Haynes Mathew George <hgeorge@codeaurora.org>
asoc: msm: Resync with upstream

 * Remove HTC's weird flush/drain handling, it's incompatible with
   our userspace.
 * Resync with upstream, keep HTC-specific features.

Change-Id: I1e0491a1b1b17801af21bc0b485aa2f6a831b68e
Copy audio_effects.h to userspace

Change-Id: Idce1c1e51b80ae58cfd663376a41cb37a0649f5b
wcnss: Configure WLAN MAC addr through user control interface

wcnss userspace service will use user control interface to configure
certain parameters required by wcnss driver. This interface is required
to configure the WLAN MAC address. These parameter was earlier written
thru module parameters from wcnss service, however that required the
wcnss userspace daemon to have the root permission.

Change-Id: I6e928a44c7f1f9ba7ab193c882bad102d8c2bd5a
CRs-fixed: 636953
Signed-off-by: Hardik Kantilal Patel <hkpatel@codeaurora.org>
stereo call recording support

Patch that allows for call recording in
stereo (left channel: TX; right channel:
RX). Tested on Nexus 5 (MSM8974). Likely
works on other recent MSM chipsets as
well.

Change-Id: I934c252283d1346f9c1f6cf786ce2f661f20a049
msm: mdss: Program unpack pattern for pipes with solidfill

When a pipe is staged with a solidfill color, we need to also
program the correct unpack pattern for the color format. If the
unpack pattern is not specified, the corresponding color layer may
not be display correctly.

Change-Id: Ic52fe29235813faa788745dd72f82edaca2635f1
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>
msm: mdss: set pipe to solid fill when releasing it

There are cases where pipe can remain active for additional vsync after
unstaging from mixer, if this ever happens it will keep fetching from
memory. In order to avoid this, we can setup the pipe in solid fill mode
so there is no memory access after pipe is released by software and
avoid potential iommu page fault or underrun since pipe is no longer
considered for bandwidth calculations.

Change-Id: I4b5a5deda8c854c504ef523df434509fa5567186
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>