1. 21 Nov, 2014 8 commits
    • Daniel Borkmann's avatar
      net: sctp: fix memory leak in auth key management · f58ee885
      Daniel Borkmann authored
      [ Upstream commit 4184b2a7 ]
      
      A very minimal and simple user space application allocating an SCTP
      socket, setting SCTP_AUTH_KEY setsockopt(2) on it and then closing
      the socket again will leak the memory containing the authentication
      key from user space:
      
      unreferenced object 0xffff8800837047c0 (size 16):
        comm "a.out", pid 2789, jiffies 4296954322 (age 192.258s)
        hex dump (first 16 bytes):
          01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff816d7e8e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811c88d8>] __kmalloc+0xe8/0x270
          [<ffffffffa0870c23>] sctp_auth_create_key+0x23/0x50 [sctp]
          [<ffffffffa08718b1>] sctp_auth_set_key+0xa1/0x140 [sctp]
          [<ffffffffa086b383>] sctp_setsockopt+0xd03/0x1180 [sctp]
          [<ffffffff815bfd94>] sock_common_setsockopt+0x14/0x20
          [<ffffffff815beb61>] SyS_setsockopt+0x71/0xd0
          [<ffffffff816e58a9>] system_call_fastpath+0x12/0x17
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      This is bad because of two things, we can bring down a machine from
      user space when auth_enable=1, but also we would leave security sensitive
      keying material in memory without clearing it after use. The issue is
      that sctp_auth_create_key() already sets the refcount to 1, but after
      allocation sctp_auth_set_key() does an additional refcount on it, and
      thus leaving it around when we free the socket.
      
      Fixes: 65b07e5d ("[SCTP]: API updates to suport SCTP-AUTH extensions.")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f58ee885
    • Daniel Borkmann's avatar
      net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet · 35890526
      Daniel Borkmann authored
      [ Upstream commit e40607cb ]
      
      An SCTP server doing ASCONF will panic on malformed INIT ping-of-death
      in the form of:
      
        ------------ INIT[PARAM: SET_PRIMARY_IP] ------------>
      
      While the INIT chunk parameter verification dissects through many things
      in order to detect malformed input, it misses to actually check parameters
      inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary
      IP address' parameter in ASCONF, which has as a subparameter an address
      parameter.
      
      So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS
      or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0
      and thus sctp_get_af_specific() returns NULL, too, which we then happily
      dereference unconditionally through af->from_addr_param().
      
      The trace for the log:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
      IP: [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
      PGD 0
      Oops: 0000 [#1] SMP
      [...]
      Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs
      RIP: 0010:[<ffffffffa01e9c62>]  [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
      [...]
      Call Trace:
       <IRQ>
       [<ffffffffa01f2add>] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp]
       [<ffffffffa01e1fcb>] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp]
       [<ffffffffa01e3751>] sctp_do_sm+0x71/0x1210 [sctp]
       [<ffffffffa01e5c09>] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp]
       [<ffffffffa01e61f6>] sctp_endpoint_bh_rcv+0x116/0x230 [sctp]
       [<ffffffffa01ee986>] sctp_inq_push+0x56/0x80 [sctp]
       [<ffffffffa01fcc42>] sctp_rcv+0x982/0xa10 [sctp]
       [<ffffffffa01d5123>] ? ipt_local_in_hook+0x23/0x28 [iptable_filter]
       [<ffffffff8148bdc9>] ? nf_iterate+0x69/0xb0
       [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
       [<ffffffff8148bf86>] ? nf_hook_slow+0x76/0x120
       [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
      [...]
      
      A minimal way to address this is to check for NULL as we do on all
      other such occasions where we know sctp_get_af_specific() could
      possibly return with NULL.
      
      Fixes: d6de3097 ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35890526
    • Marcelo Leitner's avatar
      vxlan: Do not reuse sockets for a different address family · b101a7ae
      Marcelo Leitner authored
      [ Upstream commit 19ca9fc1 ]
      
      Currently, we only match against local port number in order to reuse
      socket. But if this new vxlan wants an IPv6 socket and a IPv4 one bound
      to that port, vxlan will reuse an IPv4 socket as IPv6 and a panic will
      follow. The following steps reproduce it:
      
         # ip link add vxlan6 type vxlan id 42 group 229.10.10.10 \
             srcport 5000 6000 dev eth0
         # ip link add vxlan7 type vxlan id 43 group ff0e::110 \
             srcport 5000 6000 dev eth0
         # ip link set vxlan6 up
         # ip link set vxlan7 up
         <panic>
      
      [    4.187481] BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
      ...
      [    4.188076] Call Trace:
      [    4.188085]  [<ffffffff81667c4a>] ? ipv6_sock_mc_join+0x3a/0x630
      [    4.188098]  [<ffffffffa05a6ad6>] vxlan_igmp_join+0x66/0xd0 [vxlan]
      [    4.188113]  [<ffffffff810a3430>] process_one_work+0x220/0x710
      [    4.188125]  [<ffffffff810a33c4>] ? process_one_work+0x1b4/0x710
      [    4.188138]  [<ffffffff810a3a3b>] worker_thread+0x11b/0x3a0
      [    4.188149]  [<ffffffff810a3920>] ? process_one_work+0x710/0x710
      
      So address family must also match in order to reuse a socket.
      Reported-by: default avatarJean-Tsung Hsiao <jhsiao@redhat.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <mleitner@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b101a7ae
    • Steffen Klassert's avatar
      gre6: Move the setting of dev->iflink into the ndo_init functions. · 4dd750b4
      Steffen Klassert authored
      [ Upstream commit f03eb128 ]
      
      Otherwise it gets overwritten by register_netdev().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dd750b4
    • Steffen Klassert's avatar
      sit: Use ipip6_tunnel_init as the ndo_init function. · 6dfa82b4
      Steffen Klassert authored
      [ Upstream commit ebe084aa ]
      
      ipip6_tunnel_init() sets the dev->iflink via a call to
      ipip6_tunnel_bind_dev(). After that, register_netdevice()
      sets dev->iflink = -1. So we loose the iflink configuration
      for ipv6 tunnels. Fix this by using ipip6_tunnel_init() as the
      ndo_init function. Then ipip6_tunnel_init() is called after
      dev->iflink is set to -1 from register_netdevice().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6dfa82b4
    • Steffen Klassert's avatar
      vti6: Use vti6_dev_init as the ndo_init function. · 466f1a5f
      Steffen Klassert authored
      [ Upstream commit 16a0231b ]
      
      vti6_dev_init() sets the dev->iflink via a call to
      vti6_link_config(). After that, register_netdevice()
      sets dev->iflink = -1. So we loose the iflink configuration
      for vti6 tunnels. Fix this by using vti6_dev_init() as the
      ndo_init function. Then vti6_dev_init() is called after
      dev->iflink is set to -1 from register_netdevice().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      466f1a5f
    • Steffen Klassert's avatar
      ip6_tunnel: Use ip6_tnl_dev_init as the ndo_init function. · ba4ac5f9
      Steffen Klassert authored
      [ Upstream commit 6c6151da ]
      
      ip6_tnl_dev_init() sets the dev->iflink via a call to
      ip6_tnl_link_config(). After that, register_netdevice()
      sets dev->iflink = -1. So we loose the iflink configuration
      for ipv6 tunnels. Fix this by using ip6_tnl_dev_init() as the
      ndo_init function. Then ip6_tnl_dev_init() is called after
      dev->iflink is set to -1 from register_netdevice().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba4ac5f9
    • Greg Kroah-Hartman's avatar
      Revert "drivers/net: Disable UFO through virtio" · 41e88110
      Greg Kroah-Hartman authored
      This reverts commit 2b52d6c6 which was
      commit 3d0ad094 upstream.
      
      Ben writes:
      
      	Please drop this patch for 3.14 and 3.17.  It causes problems
      	for migration of VMs and we're probably going to revert part of
      	this.  The following patch ("drivers/net, ipv6: Select IPv6
      	fragment idents for virtio UFO packets") might no longer apply,
      	in which case you can drop that as well until we have this
      	sorted out upstream.
      
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      41e88110
  2. 14 Nov, 2014 32 commits