commit 02560982919d795e0f27167e254c767d3e66e442 Author: Willy Tarreau Date: Thu Jun 19 00:25:56 2014 +0200 Linux 2.6.32.63 Signed-off-by: Willy Tarreau commit b90422defca0edf97b3524248e239345debaf2fd Author: Willy Tarreau Date: Sat Jun 14 20:54:17 2014 +0200 net: fix regression introduced in 2.6.32.62 by sysctl fixes Commits b7c9e4ee1 ("sysctl net: Keep tcp_syn_retries inside the boundary") and eedcafdc ("net: check net.core.somaxconn sysctl values") were missing a .strategy entry which is still required in 2.6.32. Because of this, the Ubuntu kernel team has faced kernel dumps during their testing. Tyler Hicks and Luis Henriques proposed this patch to fix the issue, which properly sets .strategy as needed in 2.6.32. Reported-by: Luis Henriques Cc: tyler.hicks@canonical.com Cc: Michal Tesar Cc: David S. Miller Signed-off-by: Willy Tarreau commit a986d9c350c41fbb56b75d9da04a9725a044454a Author: Andy Lutomirski Date: Wed May 28 23:09:58 2014 -0400 auditsc: audit_krule mask accesses need bounds checking Fixes an easy DoS and possible information disclosure. This does nothing about the broken state of x32 auditing. eparis: If the admin has enabled auditd and has specifically loaded audit rules. This bug has been around since before git. Wow... Cc: stable@vger.kernel.org Signed-off-by: Andy Lutomirski Signed-off-by: Eric Paris Signed-off-by: Linus Torvalds (cherry picked from commit a3c54931199565930d6d84f4c3456f6440aefd41) [wt: no audit_filter_inode_name(), applied to audit_filter_inodes() instead] Signed-off-by: Willy Tarreau commit 07bc7fb4fcff0e24cc25abea01742e1f07d37246 Author: Thomas Gleixner Date: Tue Jun 3 12:27:08 2014 +0000 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. Signed-off-by: Thomas Gleixner Cc: Kees Cook Cc: Will Drewry Cc: Darren Hart Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds (cherry picked from commit 54a217887a7b658e2650c3feff22756ab80c7339) Signed-off-by: Willy Tarreau commit 5622af0b145d91178070b5796090c09fd427de34 Author: Thomas Gleixner Date: Tue Jun 3 12:27:07 2014 +0000 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 Cc: Kees Cook Cc: Will Drewry Cc: Darren Hart Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds (cherry picked from commit 13fbca4c6ecd96ec1a1cfa2e4f2ce191fe928a5e) [wt: adjusted context - cmpxchg_futex_value_locked() takes 3 args] Signed-off-by: Willy Tarreau commit 523b5a514d29a8fdca8c26b7e41aa7d445e4ab0d Author: Thomas Gleixner Date: Tue Jun 3 12:27:06 2014 +0000 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 Cc: Kees Cook Cc: Will Drewry Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds (cherry picked from commit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270) Signed-off-by: Willy Tarreau commit 61b2412260ddff25ec54805df83627980d4c0bf9 Author: Thomas Gleixner Date: Tue Jun 3 12:27:06 2014 +0000 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() in line with futex_wait_requeue_pi() which performs the same check as per commit 6f7b0a2a5c0f ("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 Signed-off-by: Kees Cook Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner Reviewed-by: Darren Hart Signed-off-by: Linus Torvalds (cherry picked from commit e9c243a5a6de0be8e584c604d353412584b592f8) Signed-off-by: Willy Tarreau commit 129af2db18d8d85497b1fa766553d63717876578 Author: Thomas Gleixner Date: Mon May 12 20:45:35 2014 +0000 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. Signed-off-by: Thomas Gleixner Cc: Dave Jones Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Darren Hart Cc: Davidlohr Bueso Cc: Steven Rostedt Cc: Clark Williams Cc: Paul McKenney Cc: Lai Jiangshan Cc: Roland McGrath Cc: Carlos ODonell Cc: Jakub Jelinek Cc: Michael Kerrisk Cc: Sebastian Andrzej Siewior Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org (cherry picked from commit f0d71b3dcb8332f7971b5f2363632573e6d9486a) Signed-off-by: Willy Tarreau commit 81ce5f0cae0c15d679fef2219414bb508c9c1873 Author: Thomas Gleixner Date: Mon May 12 20:45:34 2014 +0000 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. Signed-off-by: Thomas Gleixner Cc: Dave Jones Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Darren Hart Cc: Davidlohr Bueso Cc: Steven Rostedt Cc: Clark Williams Cc: Paul McKenney Cc: Lai Jiangshan Cc: Roland McGrath Cc: Carlos ODonell Cc: Jakub Jelinek Cc: Michael Kerrisk Cc: Sebastian Andrzej Siewior Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org (cherry picked from commit 866293ee54227584ffcb4a42f69c1f365974ba7f) Signed-off-by: Willy Tarreau commit d100b2748ac930237a97646ae9a4721a7f62acc1 Author: Ben Hutchings Date: Thu Dec 9 12:08:35 2010 +0000 ethtool: Report link-down while interface is down While an interface is down, many implementations of ethtool_ops::get_link, including the default, ethtool_op_get_link(), will report the last link state seen while the interface was up. In general the current physical link state is not available if the interface is down. Define ETHTOOL_GLINK to reflect whether the interface *and* any physical port have a working link, and consistently return 0 when the interface is down. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller (cherry picked from commit e596e6e4d578f2639416e620d367a3af34814a40) Cc: Wang Weidong Signed-off-by: Willy Tarreau