1. 28 4月, 2017 4 次提交
  2. 27 4月, 2017 31 次提交
  3. 26 4月, 2017 5 次提交
    • L
      Merge tag 'arc-4.11-final' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc · ea839b41
      Linus Torvalds 提交于
      Pull ARC fix from Vineet Gupta:
       "Last minute fixes for ARC:
      
         - build error in Mellanox nps platform
      
         - addressing lack of saving FPU regs in releavnt configs"
      
      * tag 'arc-4.11-final' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
        ARCv2: entry: save Accumulator register pair (r58:59) if present
        ARC: [plat-eznps] Fix build error
      ea839b41
    • E
      net: move xdp_prog field in RX cache lines · 7acedaf5
      Eric Dumazet 提交于
      (struct net_device, xdp_prog) field should be moved in RX cache lines,
      reducing latencies when a single packet is received on idle host,
      since netif_elide_gro() needs it.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7acedaf5
    • A
      net/packet: check length in getsockopt() called with PACKET_HDRLEN · fd2c83b3
      Alexander Potapenko 提交于
      In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
      |val| remains uninitialized and the syscall may behave differently
      depending on its value, and even copy garbage to userspace on certain
      architectures. To fix this we now return -EINVAL if optlen is too small.
      
      This bug has been detected with KMSAN.
      Signed-off-by: NAlexander Potapenko <glider@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd2c83b3
    • D
      net: ipv6: regenerate host route if moved to gc list · 8048ced9
      David Ahern 提交于
      Taking down the loopback device wreaks havoc on IPv6 routing. By
      extension, taking down a VRF device wreaks havoc on its table.
      
      Dmitry and Andrey both reported heap out-of-bounds reports in the IPv6
      FIB code while running syzkaller fuzzer. The root cause is a dead dst
      that is on the garbage list gets reinserted into the IPv6 FIB. While on
      the gc (or perhaps when it gets added to the gc list) the dst->next is
      set to an IPv4 dst. A subsequent walk of the ipv6 tables causes the
      out-of-bounds access.
      
      Andrey's reproducer was the key to getting to the bottom of this.
      
      With IPv6, host routes for an address have the dst->dev set to the
      loopback device. When the 'lo' device is taken down, rt6_ifdown initiates
      a walk of the fib evicting routes with the 'lo' device which means all
      host routes are removed. That process moves the dst which is attached to
      an inet6_ifaddr to the gc list and marks it as dead.
      
      The recent change to keep global IPv6 addresses added a new function,
      fixup_permanent_addr, that is called on admin up. That function restarts
      dad for an inet6_ifaddr and when it completes the host route attached
      to it is inserted into the fib. Since the route was marked dead and
      moved to the gc list, re-inserting the route causes the reported
      out-of-bounds accesses. If the device with the address is taken down
      or the address is removed, the WARN_ON in fib6_del is triggered.
      
      All of those faults are fixed by regenerating the host route if the
      existing one has been moved to the gc list, something that can be
      determined by checking if the rt6i_ref counter is 0.
      
      Fixes: f1705ec1 ("net: ipv6: Make address flushing on ifdown optional")
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8048ced9
    • X
      bridge: move bridge multicast cleanup to ndo_uninit · b1b9d366
      Xin Long 提交于
      During removing a bridge device, if the bridge is still up, a new mdb entry
      still can be added in br_multicast_add_group() after all mdb entries are
      removed in br_multicast_dev_del(). Like the path:
      
        mld_ifc_timer_expire ->
          mld_sendpack -> ...
            br_multicast_rcv ->
              br_multicast_add_group
      
      The new mp's timer will be set up. If the timer expires after the bridge
      is freed, it may cause use-after-free panic in br_multicast_group_expired.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
      IP: [<ffffffffa07ed2c8>] br_multicast_group_expired+0x28/0xb0 [bridge]
      Call Trace:
       <IRQ>
       [<ffffffff81094536>] call_timer_fn+0x36/0x110
       [<ffffffffa07ed2a0>] ? br_mdb_free+0x30/0x30 [bridge]
       [<ffffffff81096967>] run_timer_softirq+0x237/0x340
       [<ffffffff8108dcbf>] __do_softirq+0xef/0x280
       [<ffffffff8169889c>] call_softirq+0x1c/0x30
       [<ffffffff8102c275>] do_softirq+0x65/0xa0
       [<ffffffff8108e055>] irq_exit+0x115/0x120
       [<ffffffff81699515>] smp_apic_timer_interrupt+0x45/0x60
       [<ffffffff81697a5d>] apic_timer_interrupt+0x6d/0x80
      
      Nikolay also found it would cause a memory leak - the mdb hash is
      reallocated and not freed due to the mdb rehash.
      
      unreferenced object 0xffff8800540ba800 (size 2048):
        backtrace:
          [<ffffffff816e2287>] kmemleak_alloc+0x67/0xc0
          [<ffffffff81260bea>] __kmalloc+0x1ba/0x3e0
          [<ffffffffa05c60ee>] br_mdb_rehash+0x5e/0x340 [bridge]
          [<ffffffffa05c74af>] br_multicast_new_group+0x43f/0x6e0 [bridge]
          [<ffffffffa05c7aa3>] br_multicast_add_group+0x203/0x260 [bridge]
          [<ffffffffa05ca4b5>] br_multicast_rcv+0x945/0x11d0 [bridge]
          [<ffffffffa05b6b10>] br_dev_xmit+0x180/0x470 [bridge]
          [<ffffffff815c781b>] dev_hard_start_xmit+0xbb/0x3d0
          [<ffffffff815c8743>] __dev_queue_xmit+0xb13/0xc10
          [<ffffffff815c8850>] dev_queue_xmit+0x10/0x20
          [<ffffffffa02f8d7a>] ip6_finish_output2+0x5ca/0xac0 [ipv6]
          [<ffffffffa02fbfc6>] ip6_finish_output+0x126/0x2c0 [ipv6]
          [<ffffffffa02fc245>] ip6_output+0xe5/0x390 [ipv6]
          [<ffffffffa032b92c>] NF_HOOK.constprop.44+0x6c/0x240 [ipv6]
          [<ffffffffa032bd16>] mld_sendpack+0x216/0x3e0 [ipv6]
          [<ffffffffa032d5eb>] mld_ifc_timer_expire+0x18b/0x2b0 [ipv6]
      
      This could happen when ip link remove a bridge or destroy a netns with a
      bridge device inside.
      
      With Nikolay's suggestion, this patch is to clean up bridge multicast in
      ndo_uninit after bridge dev is shutdown, instead of br_dev_delete, so
      that netif_running check in br_multicast_add_group can avoid this issue.
      
      v1->v2:
        - fix this issue by moving br_multicast_dev_del to ndo_uninit, instead
          of calling dev_close in br_dev_delete.
      
      (NOTE: Depends upon b6fe0440 ("bridge: implement missing ndo_uninit()"))
      
      Fixes: e10177ab ("bridge: multicast: fix handling of temp and perm entries")
      Reported-by: NJianwen Ji <jiji@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1b9d366