1. 12 Feb, 2016 10 commits
  2. 28 Jan, 2016 4 commits
    • Florian Westphal's avatar
      connector: bump skb->users before callback invocation · 20f16f7e
      Florian Westphal authored
      [ Upstream commit 55285bf0 ]
      
      Dmitry reports memleak with syskaller program.
      Problem is that connector bumps skb usecount but might not invoke callback.
      
      So move skb_get to where we invoke the callback.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      20f16f7e
    • Xin Long's avatar
      sctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close · 7bb8b4ae
      Xin Long authored
      [ Upstream commit 068d8bd3 ]
      
      In sctp_close, sctp_make_abort_user may return NULL because of memory
      allocation failure. If this happens, it will bypass any state change
      and never free the assoc. The assoc has no chance to be freed and it
      will be kept in memory with the state it had even after the socket is
      closed by sctp_close().
      
      So if sctp_make_abort_user fails to allocate memory, we should abort
      the asoc via sctp_primitive_ABORT as well. Just like the annotation in
      sctp_sf_cookie_wait_prm_abort and sctp_sf_do_9_1_prm_abort said,
      "Even if we can't send the ABORT due to low memory delete the TCB.
      This is a departure from our typical NOMEM handling".
      
      But then the chunk is NULL (low memory) and the SCTP_CMD_REPLY cmd would
      dereference the chunk pointer, and system crash. So we should add
      SCTP_CMD_REPLY cmd only when the chunk is not NULL, just like other
      places where it adds SCTP_CMD_REPLY cmd.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7bb8b4ae
    • Andrey Ryabinin's avatar
      ipv6/addrlabel: fix ip6addrlbl_get() · 3877fb02
      Andrey Ryabinin authored
      [ Upstream commit e459dfee ]
      
      ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
      ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
      ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.
      
      Fix this by inverting ip6addrlbl_hold() check.
      
      Fixes: 2a8cc6c8 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reviewed-by: default avatarCong Wang <cwang@twopensource.com>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      3877fb02
    • Vijay Pandurangan's avatar
      veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. · 0f915418
      Vijay Pandurangan authored
      [ Upstream commit ce8c839b ]
      
      Packets that arrive from real hardware devices have ip_summed ==
      CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
      CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
      current version of veth will replace CHECKSUM_NONE with
      CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
      a veth device to be delivered to the application. This caused applications
      at Twitter to receive corrupt data when network hardware was corrupting
      packets.
      
      We believe this was added as an optimization to skip computing and
      verifying checksums for communication between containers. However, locally
      generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
      written does nothing for them. As far as we can tell, after removing this
      code, these packets are transmitted from one stack to another unmodified
      (tcpdump shows invalid checksums on both sides, as expected), and they are
      delivered correctly to applications. We didn’t test every possible network
      configuration, but we tried a few common ones such as bridging containers,
      using NAT between the host and a container, and routing from hardware
      devices to containers. We have effectively deployed this in production at
      Twitter (by disabling RX checksum offloading on veth devices).
      
      This code dates back to the first version of the driver, commit
      <e314dbdc> ("[NET]: Virtual ethernet device driver"), so I
      suspect this bug occurred mostly because the driver API has evolved
      significantly since then. Commit <0b796750> ("net/veth: Fix
      packet checksumming") (in December 2010) fixed this for packets that get
      created locally and sent to hardware devices, by not changing
      CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
      in from hardware devices.
      Co-authored-by: default avatarEvan Jones <ej@evanjones.ca>
      Signed-off-by: default avatarEvan Jones <ej@evanjones.ca>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Phil Sutter <phil@nwl.cc>
      Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarVijay Pandurangan <vijayp@vijayp.ca>
      Acked-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      0f915418
  3. 27 Jan, 2016 26 commits