omap4-common: allow mediaserver to open a CAIF socket

Change-Id: Idf4f6a03d1a8ef72e233b3f806e7471cc29b7752
Revert "Merge omapzoom-changes into drivers/video/omap2/dss/dispc.c"

This seems to be the real cause for the rare SODs, revert it for now.

This reverts commit 0313c87cd8ea16810d7a9239045160e093bbce70.

Conflicts:
	drivers/video/omap2/dss/dispc.c

Change-Id: I6a889b39a73afb742ae05a06deb37db30d6454e9
Revert "Revert "omap4-common: fix wake on unplug""

This commit did not cause SODs, let's get it back.

This reverts commit c41b94fe5d135e9ef49dc4e69aca751d4b0e2367.

Change-Id: I73aced42568d0bc830345c28198e06de41767114
ti-st: tty_hci: Check kzalloc return value.

Check for error condition returned by kzalloc.

Change-Id: I658cba57b9177ff68feb63d6a0e701d2a226960f
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
ti-st: tty_hci: Remove redundant assignment.

Clean up for the code: remove redundant assignment.

Change-Id: I595b549fedec4c89177f342c957e95668f184442
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
ti-st: tty_hci: Fix race condition in hci_tty_open.

Race condition is possible in the hci_tty driver.
The race result in NULL pointer dereference due to
struct sk_buff_head rx_list is used without prior
initialization.

The error condition can easily reproduced with the script
and COM-7 wilink hardware module:
while [ 1 ]; do echo -n "fail" > /dev/nfc; sleep 2; done

[   56.229614] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   56.238494] pgd = c0004000
[   56.241485] [00000000] *pgd=00000000
[   56.245513] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   56.251586] Modules linked in: rproc_drm(O) tf_driver(O) gps_drv wl18xx(O) wl12xx(O) wlcore(O) mac80211(O) pvrsrvkm_sgx544_112(O) cfg80211(O) compat(O) [last unloaded: wlcore_sdio]
[   56.270141] CPU: 0    Tainted: G        W  O  (3.4.34-01546-g66a9034 #82)
[   56.277618] PC is at skb_queue_tail+0x2c/0x50
[   56.282409] LR is at _raw_spin_lock_irqsave+0x10/0x14
[   56.287994] pc : [<c04eeb04>]    lr : [<c0686618>]    psr: 60000193
[   56.287994] sp : d6cbde60  ip : d6cbde50  fp : d6cbde7c
[   56.300628] r10: d6ecf5d4  r9 : d6ecf558  r8 : 00000000
[   56.306335] r7 : d6ecf5ac  r6 : cb78347c  r5 : d67c6500  r4 : cb783470
[   56.313537] r3 : 00000000  r2 : a0000193  r1 : d67c6500  r0 : a0000193
[   56.320648] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   56.328796] Control: 10c5387d  Table: 8b6a804a  DAC: 00000015
       [skiped ...]
[   57.452667] Backtrace:
[   57.455474] [<c04eead8>] (skb_queue_tail+0x0/0x50) from [<c0300bec>] (st_receive+0x18/0x34)
[   57.464630]  r6:d5920c59 r5:00000004 r4:cb783440 r3:c0300bd4
[   57.471191] [<c0300bd4>] (st_receive+0x0/0x34) from [<c02fe924>] (st_send_frame+0x50/0xac)
[   57.480255]  r4:d6ecf540 r3:c0300bd4
[   57.484344] [<c02fe8d4>] (st_send_frame+0x0/0xac) from [<c02ff13c>] (st_int_recv+0x1fc/0x3a0)
[   57.493713]  r5:00000000 r4:d6ecf540
[   57.497894] [<c02fef40>] (st_int_recv+0x0/0x3a0) from [<c02fe548>] (st_tty_receive+0x24/0x28)
[   57.507171] [<c02fe524>] (st_tty_receive+0x0/0x28) from [<c02bbac0>] (flush_to_ldisc+0x150/0x1b4)
[   57.516906] [<c02bb970>] (flush_to_ldisc+0x0/0x1b4) from [<c0061950>] (process_one_work+0x134/0x4ac)
[   57.526916] [<c006181c>] (process_one_work+0x0/0x4ac) from [<c0061e54>] (worker_thread+0x18c/0x3d8)
[   57.536865] [<c0061cc8>] (worker_thread+0x0/0x3d8) from [<c00668d0>] (kthread+0x90/0x9c)
[   57.545684] [<c0066840>] (kthread+0x0/0x9c) from [<c004a8a8>] (do_exit+0x0/0x804)
[   57.553894]  r6:c004a8a8 r5:c0066840 r4:d6c5dec4

Change-Id: Ife34d53b4fad45d1db600d71450b06dce0328b2c
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
ti-st: tty_hci: Properly unregister protocols in open.

In case of error condition registered protocols were not
unregistered from st core when open syscall was called. Memory
allocated for the driver data was just freed. Then callback
from st_register() called st_reg_complete_cb, and complete()
had the argument from the already freed memory.

This could be the reason of the null pointer dereference, as in
the log below. The issue is rarely reproduced.

[  132.189086] (stc): st_register(12)
[  132.198394] (stc):  chnl_id list empty :12
[  132.205352] (stk) : st_kim_start
[  132.329040] (stk) :ldisc_install = 1
[  133.087829] mtp_open
[  133.329010] (stk) :ldisc installation timeout
[  133.334960] (stk) :ldisc_install = 0
[  134.336853] (stk) : timed out waiting for ldisc to be un-installed
[  134.463165] (stk) :ldisc_install = 1
[  135.469757] (stk) :ldisc installation timeout
[  135.474334] (stk) :ldisc_install = 0
[  135.557830] init: sys_prop: permission denied uid:1003 name:service.bootanim.exit
[  135.653076] init: Boot Animation exit
[  135.895965] (hci_tty): inside hci_tty_open (d66bce38, d66ff480)
[  135.902435] (stc): st_register(4)
[  135.906494] (stc):  ST_REG_IN_PROGRESS:4
[  135.910858] (stc): add_channel_to_table: id 4
[  136.477478] (stk) : timed out waiting for ldisc to be un-installed
[  136.594635] (stk) :ldisc_install = 1
[  137.595001] (stk) :ldisc installation timeout
[  137.603759] (stk) :ldisc_install = 0
[  138.602508] (stk) : timed out waiting for ldisc to be un-installed
[  138.727478] (stk) :ldisc_install = 1
[  139.727722] (stk) :ldisc installation timeout
[  139.733734] (stk) :ldisc_install = 0
[  140.580657] binder: release 1324:1324 transaction 19588 out, still active
[  140.735321] (stk) : timed out waiting for ldisc to be un-installed
[  140.852447] (stk) :ldisc_install = 1
[  141.852478] (stk) :ldisc installation timeout
[  141.857360] (stk) :ldisc_install = 0
[  141.914978] (hci_tty): Timeout(6 sec),didn't get reg completion signal from ST
[  142.868072] (stk) : timed out waiting for ldisc to be un-installed
[  142.985382] (stk) :ldisc_install = 1
[  143.985351] (stk) :ldisc installation timeout
[  143.991546] (stk) :ldisc_install = 0
[  144.993072] (stk) : timed out waiting for ldisc to be un-installed
[  145.002960] (stc):  KIM failure complete callback
[  145.008392] (stc):  st_reg_complete
[  145.012725] (hci_tty): @ st_reg_completion_cb
[  145.017639] Unable to handle kernel NULL pointer dereference at virtual address 00000010
[  145.026428] pgd = c7cc0000
[  145.029388] [00000010] *pgd=00000000
[  145.033386] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[  145.039215] Modules linked in: rproc_drm(O) tf_driver(O) gps_drv wl18xx(O) wl12xx(O) wlcore(O) mac80211(O) cfg80211(O) pvrsrvkm_sgx540_120(O) compat(O)
[  145.054870] CPU: 1    Tainted: G        W  O  (3.4.34 #1)
[  145.060821] PC is at __wake_up_common+0x2c/0x94
[  145.065734] LR is at complete+0x4c/0x60
[  145.069915] pc : [<c006ee4c>]    lr : [<c0070378>]    psr: a0000093
         [skiped...]
[  146.023742] Backtrace:
[  146.026550] [<c006ee20>] (__wake_up_common+0x0/0x94) from [<c0070378>] (complete+0x4c/0x60)
[  146.035644] [<c007032c>] (complete+0x0/0x60) from [<c0301f20>] (st_reg_completion_cb+0x30/0x38)
[  146.045104]  r6:d6ef5cd0 r5:00000092 r4:d617dd40
[  146.050384] [<c0301ef0>] (st_reg_completion_cb+0x0/0x38) from [<c02ffd34>] (st_reg_complete+0x60/0xa8)
[  146.060516]  r5:d6ef5cc4 r4:00000004
[  146.064575] [<c02ffcd4>] (st_reg_complete+0x0/0xa8) from [<c02fffac>] (st_register+0x230/0x324)
[  146.074066] [<c02ffd7c>] (st_register+0x0/0x324) from [<c0323cac>] (nfc_drv_open+0xe8/0x1e4)
[  146.083251]  r7:c8ec3840 r6:c0a5f89c r5:00000000 r4:c6016140
[  146.089752] [<c0323bc4>] (nfc_drv_open+0x0/0x1e4) from [<c0117aec>] (chrdev_open+0x9c/0x164)
[  146.098937] [<c0117a50>] (chrdev_open+0x0/0x164) from [<c0111b88>] (__dentry_open+0x200/0x2b8)
[  146.108306]  r8:c0117a50 r7:d66b1b28 r6:d5e1e910 r5:d69806f0 r4:c8ec3840
[  146.115997] [<c0111988>] (__dentry_open+0x0/0x2b8) from [<c0112c24>] (nameidata_to_filp+0x68/0x70)
[  146.125701] [<c0112bbc>] (nameidata_to_filp+0x0/0x70) from [<c01211ac>] (do_last.isra.20+0x150/0x6d4)
[  146.135711]  r7:00000026 r6:00000000 r5:00020002 r4:c6ccfed8
[  146.142272] [<c012105c>] (do_last.isra.20+0x0/0x6d4) from [<c0121954>] (path_openat+0xc0/0x3b8)
[  146.151672] [<c0121894>] (path_openat+0x0/0x3b8) from [<c0121d5c>] (do_filp_open+0x34/0x88)
[  146.160766] [<c0121d28>] (do_filp_open+0x0/0x88) from [<c0112d20>] (do_sys_open+0xf4/0x18c)
[  146.169830]  r7:00000001 r6:00000027 r5:00020002 r4:d63d1000
[  146.176330] [<c0112c2c>] (do_sys_open+0x0/0x18c) from [<c0112de0>] (sys_open+0x28/0x2c)
[  146.185058] [<c0112db8>] (sys_open+0x0/0x2c) from [<c0013680>] (ret_fast_syscall+0x0/0x30)
[  146.194061] Code: e1a08003 e50b2030 e157000c e59b9004 (e41c400c)
[

Change-Id: I10085ef1b1bc91ce3be01e179aa995287af271f1
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
drivers:misc: ti-st: fix potential NULL pointer dereference in st_register()

drivers:misc: ti-st: fix potential NULL pointer dereference in st_register()

Remove the pointless NULL dereference above the NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ti-st: use cpu friendly wait_for_completions

Be nice to CPU and don't hog the resources, use a nice wait_for_interruptible
timeout for completions instead of wait_for_timeout which is
non-interruptible.

Change-Id: I87542c2980978543bc3832f45592b719a61ba5b8
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ti-st: use msleep_interruptible instead of mdelay

Be nice to CPU and use msleep_interruptible instead of msleep which chops the
CPU up into a spin loop.
Used for all delays > 20ms.

Change-Id: I8f84ff34d9191e8fde9af28f81681470571c0b51
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
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: I03941dc5737bcb9d3ddd2ec88f7c263c27a1247d
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: I5242efcdc3c08159c652fe645e1f85b27687e6ca
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: I473bf486ad451de0bfd049a110b69795a6fda451
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: Ic8714ed2e9dee323a011eed42f7c0159c65dfbf3
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: I4eeb2e139b720f1dd46e43407a96b3d9a19aacd1
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: Ic410036b38ccb7289b3d58eff56ad64d3a9dcada
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
Merge remote-tracking branch 'upstream/cm-11.0' into cm-11.0