1. 22 Oct, 2015 36 commits
  2. 18 Sep, 2015 4 commits
    • Zefan Li's avatar
      Linux 3.4.109 · 4a55c0cf
      Zefan Li authored
      4a55c0cf
    • Eric Dumazet's avatar
      udp: fix behavior of wrong checksums · 1c50a0ae
      Eric Dumazet authored
      commit beb39db5 upstream.
      
      We have two problems in UDP stack related to bogus checksums :
      
      1) We return -EAGAIN to application even if receive queue is not empty.
         This breaks applications using edge trigger epoll()
      
      2) Under UDP flood, we can loop forever without yielding to other
         processes, potentially hanging the host, especially on non SMP.
      
      This patch is an attempt to make things better.
      
      We might in the future add extra support for rt applications
      wanting to better control time spent doing a recv() in a hostile
      environment. For example we could validate checksums before queuing
      packets in socket receive queue.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      1c50a0ae
    • Thomas Gleixner's avatar
      sched: Queue RT tasks to head when prio drops · aaedb090
      Thomas Gleixner authored
      commit 81a44c54 upstream.
      
      The following scenario does not work correctly:
      
      Runqueue of CPUx contains two runnable and pinned tasks:
      
       T1: SCHED_FIFO, prio 80
       T2: SCHED_FIFO, prio 80
      
      T1 is on the cpu and executes the following syscalls (classic priority
      ceiling scenario):
      
       sys_sched_setscheduler(pid(T1), SCHED_FIFO, .prio = 90);
       ...
       sys_sched_setscheduler(pid(T1), SCHED_FIFO, .prio = 80);
       ...
      
      Now T1 gets preempted by T3 (SCHED_FIFO, prio 95). After T3 goes back
      to sleep the scheduler picks T2. Surprise!
      
      The same happens w/o actual preemption when T1 is forced into the
      scheduler due to a sporadic NEED_RESCHED event. The scheduler invokes
      pick_next_task() which returns T2. So T1 gets preempted and scheduled
      out.
      
      This happens because sched_setscheduler() dequeues T1 from the prio 90
      list and then enqueues it on the tail of the prio 80 list behind T2.
      This violates the POSIX spec and surprises user space which relies on
      the guarantee that SCHED_FIFO tasks are not scheduled out unless they
      give the CPU up voluntarily or are preempted by a higher priority
      task. In the latter case the preempted task must get back on the CPU
      after the preempting task schedules out again.
      
      We fixed a similar issue already in commit 60db48ca (sched: Queue a
      deboosted task to the head of the RT prio queue). The same treatment
      is necessary for sched_setscheduler(). So enqueue to head of the prio
      bucket list if the priority of the task is lowered.
      
      It might be possible that existing user space relies on the current
      behaviour, but it can be considered highly unlikely due to the corner
      case nature of the application scenario.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1391803122-4425-6-git-send-email-bigeasy@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      aaedb090
    • Ben Hutchings's avatar
      pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic · a39bf4a8
      Ben Hutchings authored
      pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
      the first time atomically and the second time not.  The second attempt
      needs to continue from the iovec position, pipe buffer offset and
      remaining length where the first attempt failed, but currently the
      pipe buffer offset and remaining length are reset.  This will corrupt
      the piped data (possibly also leading to an information leak between
      processes) and may also corrupt kernel memory.
      
      This was fixed upstream by commits f0d1bec9 ("new helper:
      copy_page_from_iter()") and 637b58c2 ("switch pipe_read() to
      copy_page_to_iter()"), but those aren't suitable for stable.  This fix
      for older kernel versions was made by Seth Jennings for RHEL and I
      have extracted it from their update.
      
      CVE-2015-1805
      
      References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      [lizf: Backported to 3.4: adjust context]
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      a39bf4a8