GitHub PushEvent at 2014-07-03 18:45:39
Repository: android_kernel_pantech_ef60s
Actor: mokeeopensource
Payload: {"shas":[["0b557d1a954d54312d529a65b6a29472bad8f92f","4b8373d016f277527198385ba72fda0feb5da015@hurleysoftware.com","n_tty: Fix n_tty_write crash when echoing in raw mode\n\nThe tty atomic_write_lock does not provide an exclusion guarantee for\nthe tty driver if the termios settings are LECHO & !OPOST.  And since\nit is unexpected and not allowed to call TTY buffer helpers like\ntty_insert_flip_string concurrently, this may lead to crashes when\nconcurrect writers call pty_write. In that case the following two\nwriters:\n* the ECHOing from a workqueue and\n* pty_write from the process\nrace and can overflow the corresponding TTY buffer like follows.\n\nIf we look into tty_insert_flip_string_fixed_flag, there is:\n  int space = __tty_buffer_request_room(port, goal, flags);\n  struct tty_buffer *tb = port->buf.tail;\n  ...\n  memcpy(char_buf_ptr(tb, tb->used), chars, space);\n  ...\n  tb->used += space;\n\nso the race of the two can result in something like this:\n              A                                B\n__tty_buffer_request_room\n                                  __tty_buffer_request_room\nmemcpy(buf(tb->used), ...)\ntb->used += space;\n                                  memcpy(buf(tb->used), ...) ->BOOM\n\nB's memcpy is past the tty_buffer due to the previous A's tb->used\nincrement.\n\nSince the N_TTY line discipline input processing can output\nconcurrently with a tty write, obtain the N_TTY ldisc output_lock to\nserialize echo output with normal tty writes.  This ensures the tty\nbuffer helper tty_insert_flip_string is not called concurrently and\neverything is fine.\n\nNote that this is nicely reproducible by an ordinary user using\nforkpty and some setup around that (raw termios + ECHO). And it is\npresent in kernels at least after commit\nd945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to\nuse the normal buffering logic) in 2.6.31-rc3.\n\njs: add more info to the commit log\njs: switch to bool\njs: lock unconditionally\njs: lock only the tty->ops->write call\n\nChange-Id: I9d3d7b4a3bbd719ced5192c417b4338774447993\nReferences: CVE-2014-0196\nReported-and-tested-by: Jiri Slaby <jslaby@suse.cz>\nSigned-off-by: Peter Hurley <peter@hurleysoftware.com>\nSigned-off-by: Jiri Slaby <jslaby@suse.cz>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Alan Cox <alan@lxorguk.ukuu.org.uk>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Peter Hurley",true],["f77dd24a9b5e56e6b6d4c9d19a10d5411823ccff","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","futex: Prevent attaching to kernel threads\n\nWe happily allow userspace to declare a random kernel thread to be the\nowner of a user space PI futex.\n\nFound while analysing the fallout of Dave Jones syscall fuzzer.\n\nWe also should validate the thread group for private futexes and find\nsome fast way to validate whether the \"alleged\" owner has RW access on\nthe file which backs the SHM, but that's a separate issue.\n\nSigned-off-by: Thomas Gleixner <tglx@...utronix.de>\nCc: Dave Jones <davej@...hat.com>\nCc: Linus Torvalds <torvalds@...ux-foundation.org>\nCc: Peter Zijlstra <peterz@...radead.org>\nCc: Darren Hart <darren@...art.com>\nCc: Davidlohr Bueso <davidlohr@...com>\nCc: Steven Rostedt <rostedt@...dmis.org>\nCc: Clark Williams <williams@...hat.com>\nCc: Paul McKenney <paulmck@...ux.vnet.ibm.com>\nCc: Lai Jiangshan <laijs@...fujitsu.com>\nCc: Roland McGrath <roland@...k.frob.com>\nCc: Carlos ODonell <carlos@...hat.com>\nCc: Jakub Jelinek <jakub@...hat.com>\nCc: Michael Kerrisk <mtk.manpages@...il.com>\nCc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>\nLink: http://lkml.kernel.org/r/20140512201701.194824402@...utronix.de\nSigned-off-by: Thomas Gleixner <tglx@...utronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>\n\nChange-Id: I7444c58d00cbded35b078331a8740e8431cb13a5","Thomas Gleixner",true],["4a81fb0fc7c380a93e8d2381a3590c7341257fe8","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","futex: Add another early deadlock detection check\n\nDave Jones trinity syscall fuzzer exposed an issue in the deadlock\ndetection code of rtmutex:\n  http://lkml.kernel.org/r/20140429151655.GA14277@...hat.com\n\nThat underlying issue has been fixed with a patch to the rtmutex code,\nbut the futex code must not call into rtmutex in that case because\n    - it can detect that issue early\n    - it avoids a different and more complex fixup for backing out\n\nIf the user space variable got manipulated to 0x80000000 which means\nno lock holder, but the waiters bit set and an active pi_state in the\nkernel is found we can figure out the recursive locking issue by\nlooking at the pi_state owner. If that is the current task, then we\ncan safely return -EDEADLK.\n\nThe check should have been added in commit 59fa62451 (futex: Handle\nfutex_pi OWNER_DIED take over correctly) already, but I did not see\nthe above issue caused by user space manipulation back then.\n\nSigned-off-by: Thomas Gleixner <tglx@...utronix.de>\nCc: Dave Jones <davej@...hat.com>\nCc: Linus Torvalds <torvalds@...ux-foundation.org>\nCc: Peter Zijlstra <peterz@...radead.org>\nCc: Darren Hart <darren@...art.com>\nCc: Davidlohr Bueso <davidlohr@...com>\nCc: Steven Rostedt <rostedt@...dmis.org>\nCc: Clark Williams <williams@...hat.com>\nCc: Paul McKenney <paulmck@...ux.vnet.ibm.com>\nCc: Lai Jiangshan <laijs@...fujitsu.com>\nCc: Roland McGrath <roland@...k.frob.com>\nCc: Carlos ODonell <carlos@...hat.com>\nCc: Jakub Jelinek <jakub@...hat.com>\nCc: Michael Kerrisk <mtk.manpages@...il.com>\nCc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>\nLink: http://lkml.kernel.org/r/20140512201701.097349971@...utronix.de\nSigned-off-by: Thomas Gleixner <tglx@...utronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>\n\nChange-Id: I245f77622443435cf36bbd157b98798c235acdb0","Thomas Gleixner",true],["77636d809e94a55d946e16fb6ad434054a77766f","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)\n\nIf uaddr == uaddr2, then we have broken the rule of only requeueing\nfrom a non-pi futex to a pi futex with this call. If we attempt this,\nthen dangling pointers may be left for rt_waiter resulting in an\nexploitable condition.\n\nThis change brings futex_requeue() into line with\nfutex_wait_requeue_pi() which performs the same check as per commit\n6f7b0a2a5 (futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi())\n\n[ tglx: Compare the resulting keys as well, as uaddrs might be\n  \tdifferent depending on the mapping ]\n\nFixes CVE-2014-3153.\n\nReported-by: Pinkie Pie\nSigned-off-by: Will Drewry <wad@chromium.org>\nSigned-off-by: Kees Cook <keescook@chromium.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\n\nChange-Id: Iea1dfe1d877d63a374db2623dca6cea4e7a544b9","Thomas Gleixner",true],["6a87ab5f33383fbfb1114456d888163fe33a960b","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","futex: Validate atomic acquisition in futex_lock_pi_atomic()\n\nWe need to protect the atomic acquisition in the kernel against rogue\nuser space which sets the user space futex to 0, so the kernel side\nacquisition succeeds while there is existing state in the kernel\nassociated to the real owner.\n\nVerify whether the futex has waiters associated with kernel state. If\nit has, return -EINVAL. The state is corrupted already, so no point in\ncleaning it up. Subsequent calls will fail as well. Not our problem.\n\n[ tglx: Use futex_top_waiter() and explain why we do not need to try\n  \trestoring the already corrupted user space state. ]\n\nSigned-off-by: Darren Hart <dvhart@linux.intel.com>\nCc: Kees Cook <keescook@chromium.org>\nCc: Will Drewry <wad@chromium.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\n\nChange-Id: I6c19ae4a5e85fbc9c560723e672d5136c4786ab6","Thomas Gleixner",true],["83bd670c5c892b14129fe36a0c78d50e6c4b32af","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","futex: Always cleanup owner tid in unlock_pi\n\nIf the owner died bit is set at futex_unlock_pi, we currently do not\ncleanup the user space futex. So the owner TID of the current owner\n(the unlocker) persists. That's observable inconsistant state,\nespecially when the ownership of the pi state got transferred.\n\nClean it up unconditionally.\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Kees Cook <keescook@chromium.org>\nCc: Will Drewry <wad@chromium.org>\nCc: Darren Hart <dvhart@linux.intel.com>\nCc: stable@vger.kernel.org\n\nChange-Id: Ic84473a62bdf3e5702f46e04b266afa38e9ec40e","Thomas Gleixner",true],["688a7ce7cb07eab01742e44ac293044384079e3a","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","futex: Make lookup_pi_state more robust\n\nThe current implementation of lookup_pi_state has ambigous handling of\nthe TID value 0 in the user space futex. We can get into the kernel\neven if the TID value is 0, because either there is a stale waiters\nbit or the owner died bit is set or we are called from the requeue_pi\npath or from user space just for fun.\n\nThe current code avoids an explicit sanity check for pid = 0 in case\nthat kernel internal state (waiters) are found for the user space\naddress. This can lead to state leakage and worse under some\ncircumstances.\n\nHandle the cases explicit:\n\n     Waiter | pi_state | pi->owner | uTID      | uODIED | ?\n\n[1]  NULL   | ---      | ---       | 0         | 0/1    | Valid\n[2]  NULL   | ---      | ---       | >0        | 0/1    | Valid\n\n[3]  Found  | NULL     | --        | Any       | 0/1    | Invalid\n\n[4]  Found  | Found    | NULL      | 0         | 1      | Valid\n[5]  Found  | Found    | NULL      | >0        | 1      | Invalid\n\n[6]  Found  | Found    | task      | 0         | 1      | Valid\n\n[7]  Found  | Found    | NULL      | Any       | 0      | Invalid\n\n[8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid\n[9]  Found  | Found    | task      | 0         | 0      | Invalid\n[10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid\n\n[1]  Indicates that the kernel can acquire the futex atomically. We\n     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.\n\n[2]  Valid, if TID does not belong to a kernel thread. If no matching\n     thread is found then it indicates that the owner TID has died.\n\n[3]  Invalid. The waiter is queued on a non PI futex\n\n[4]  Valid state after exit_robust_list(), which sets the user space\n     value to FUTEX_WAITERS | FUTEX_OWNER_DIED.\n\n[5]  The user space value got manipulated between exit_robust_list()\n     and exit_pi_state_list()\n\n[6]  Valid state after exit_pi_state_list() which sets the new owner in\n     the pi_state but cannot access the user space value.\n\n[7]  pi_state->owner can only be NULL when the OWNER_DIED bit is set.\n\n[8]  Owner and user space value match\n\n[9]  There is no transient state which sets the user space TID to 0\n     except exit_robust_list(), but this is indicated by the\n     FUTEX_OWNER_DIED bit. See [4]\n\n[10] There is no transient state which leaves owner and user space\n     TID out of sync.\n\nBackport to 3.13\n  conflicts: kernel/futex.c\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: John Johansen <john.johansen@canonical.com>\nCc: Kees Cook <keescook@chromium.org>\nCc: Will Drewry <wad@chromium.org>\nCc: Darren Hart <dvhart@linux.intel.com>\nCc: stable@vger.kernel.org\n\nChange-Id: I967e3bb07b239941ea51af6b09d61d7b08138f40","Thomas Gleixner",true],["4c90df4467ed1d5484a3aa07f68a4d825ba428f1","d82e4e688aab93061c546f47d62086e69f23642a@codeaurora.org","msm: display: Add pipe type selection in overlay request\n\nAllow user to specify the type when requesting an overlay pipe.\nIf field is set the pipe type indication in the flags will be\nignored.\nChange-Id: Iee51d24b96c7a2a987dc70a439342e6548dfc8fa\nSigned-off-by: Vineet Bajaj <vbajaj@codeaurora.org>","Vineet Bajaj",true],["2365eaf23b6e64408419852cb0094e8a6644be14","239d0dcf4c4fca4a9859e3f56c56755f6b1aec1c@mokeedev.com","Merge branch 'cm-11.0' into kk_mkt","martincz",true]],"size":9,"ref":"refs/heads/kk_mkt","head":"2365eaf23b6e64408419852cb0094e8a6644be14"}