1. 21 Apr, 2015 9 commits
  2. 13 Apr, 2015 28 commits
  3. 10 Apr, 2015 3 commits
    • D.S. Ljungmark's avatar
      ipv6: Don't reduce hop limit for an interface · 150193b9
      D.S. Ljungmark authored
      commit 6fd99094 upstream.
      
      A local route may have a lower hop_limit set than global routes do.
      
      RFC 3756, Section 4.2.7, "Parameter Spoofing"
      
      >   1.  The attacker includes a Current Hop Limit of one or another small
      >       number which the attacker knows will cause legitimate packets to
      >       be dropped before they reach their destination.
      
      >   As an example, one possible approach to mitigate this threat is to
      >   ignore very small hop limits.  The nodes could implement a
      >   configurable minimum hop limit, and ignore attempts to set it below
      >   said limit.
      Signed-off-by: default avatarD.S. Ljungmark <ljungmark@modio.se>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      150193b9
    • Tejun Heo's avatar
      writeback: fix possible underflow in write bandwidth calculation · 20a63e55
      Tejun Heo authored
      commit c72efb65 upstream.
      
      From 1ebf33901ecc75d9496862dceb1ef0377980587c Mon Sep 17 00:00:00 2001
      From: Tejun Heo <tj@kernel.org>
      Date: Mon, 23 Mar 2015 00:08:19 -0400
      
      2f800fbd ("writeback: fix dirtied pages accounting on redirty")
      introduced account_page_redirty() which reverts stat updates for a
      redirtied page, making BDI_DIRTIED no longer monotonically increasing.
      
      bdi_update_write_bandwidth() uses the delta in BDI_DIRTIED as the
      basis for bandwidth calculation.  While unlikely, since the above
      patch, the newer value may be lower than the recorded past value and
      nunderflow the bandwidth calculation leading to a wild result.
      
      Fix it by subtracing min of the old and new values when calculating
      delta.  AFAIK, there hasn't been any report of it happening but the
      resulting erratic behavior would be non-critical and temporary, so
      it's possible that the issue is happening without being reported.  The
      risk of the fix is very low, so tagged for -stable.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Greg Thelen <gthelen@google.com>
      Fixes: 2f800fbd ("writeback: fix dirtied pages accounting on redirty")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      20a63e55
    • Vineet Gupta's avatar
      ARC: SA_SIGINFO ucontext regs off-by-one · 9084ed5e
      Vineet Gupta authored
      commit 6914e1e3 upstream.
      
      The regfile provided to SA_SIGINFO signal handler as ucontext was off by
      one due to pt_regs gutter cleanups in 2013.
      
      Before handling signal, user pt_regs are copied onto user_regs_struct and copied
      back later. Both structs are binary compatible. This was all fine until
      commit 2fa91904 (ARC: pt_regs update #2) which removed the empty stack slot
      at top of pt_regs (corresponding to first pad) and made the corresponding
      fixup in struct user_regs_struct (the pad in there was moved out of
      @scratch - not removed altogether as it is part of ptrace ABI)
      
       struct user_regs_struct {
      +       long pad;
              struct {
      -               long pad;
                      long bta, lp_start, lp_end,....
              } scratch;
       ...
       }
      
      This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
      signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
      which is what this commit does.
      
      This problem was hidden for 2 years, because both save/restore, despite
      using wrong location, were using the same location. Only an interim
      inspection (reproducer below) exposed the issue.
      
           void handle_segv(int signo, siginfo_t *info, void *context)
           {
       	ucontext_t *uc = context;
      	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
      
      	printf("regs %x %x\n",               <=== prints 7 8 (vs. 8 9)
                     regs->scratch.r8, regs->scratch.r9);
           }
      
           int main()
           {
      	struct sigaction sa;
      
      	sa.sa_sigaction = handle_segv;
      	sa.sa_flags = SA_SIGINFO;
      	sigemptyset(&sa.sa_mask);
      	sigaction(SIGSEGV, &sa, NULL);
      
      	asm volatile(
      	"mov	r7, 7	\n"
      	"mov	r8, 8	\n"
      	"mov	r9, 9	\n"
      	"mov	r10, 10	\n"
      	:::"r7","r8","r9","r10");
      
      	*((unsigned int*)0x10) = 0;
           }
      
      Fixes: 2fa91904 "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9084ed5e