1. 23 Apr, 2020 1 commit
    • Xin Long's avatar
      ip_vti: receive ipip packet by calling ip_tunnel_rcv · 976eba8a
      Xin Long authored
      In Commit dd9ee344 ("vti4: Fix a ipip packet processing bug in
      'IPCOMP' virtual tunnel"), it tries to receive IPIP packets in vti
      by calling xfrm_input(). This case happens when a small packet or
      frag sent by peer is too small to get compressed.
      
      However, xfrm_input() will still get to the IPCOMP path where skb
      sec_path is set, but never dropped while it should have been done
      in vti_ipcomp4_protocol.cb_handler(vti_rcv_cb), as it's not an
      ipcomp4 packet. This will cause that the packet can never pass
      xfrm4_policy_check() in the upper protocol rcv functions.
      
      So this patch is to call ip_tunnel_rcv() to process IPIP packets
      instead.
      
      Fixes: dd9ee344 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel")
      Reported-by: default avatarXiumei Mu <xmu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      976eba8a
  2. 21 Apr, 2020 3 commits
    • Xin Long's avatar
      xfrm: call xfrm_output_gso when inner_protocol is set in xfrm_output · a204aef9
      Xin Long authored
      An use-after-free crash can be triggered when sending big packets over
      vxlan over esp with esp offload enabled:
      
        [] BUG: KASAN: use-after-free in ipv6_gso_pull_exthdrs.part.8+0x32c/0x4e0
        [] Call Trace:
        []  dump_stack+0x75/0xa0
        []  kasan_report+0x37/0x50
        []  ipv6_gso_pull_exthdrs.part.8+0x32c/0x4e0
        []  ipv6_gso_segment+0x2c8/0x13c0
        []  skb_mac_gso_segment+0x1cb/0x420
        []  skb_udp_tunnel_segment+0x6b5/0x1c90
        []  inet_gso_segment+0x440/0x1380
        []  skb_mac_gso_segment+0x1cb/0x420
        []  esp4_gso_segment+0xae8/0x1709 [esp4_offload]
        []  inet_gso_segment+0x440/0x1380
        []  skb_mac_gso_segment+0x1cb/0x420
        []  __skb_gso_segment+0x2d7/0x5f0
        []  validate_xmit_skb+0x527/0xb10
        []  __dev_queue_xmit+0x10f8/0x2320 <---
        []  ip_finish_output2+0xa2e/0x1b50
        []  ip_output+0x1a8/0x2f0
        []  xfrm_output_resume+0x110e/0x15f0
        []  __xfrm4_output+0xe1/0x1b0
        []  xfrm4_output+0xa0/0x200
        []  iptunnel_xmit+0x5a7/0x920
        []  vxlan_xmit_one+0x1658/0x37a0 [vxlan]
        []  vxlan_xmit+0x5e4/0x3ec8 [vxlan]
        []  dev_hard_start_xmit+0x125/0x540
        []  __dev_queue_xmit+0x17bd/0x2320  <---
        []  ip6_finish_output2+0xb20/0x1b80
        []  ip6_output+0x1b3/0x390
        []  ip6_xmit+0xb82/0x17e0
        []  inet6_csk_xmit+0x225/0x3d0
        []  __tcp_transmit_skb+0x1763/0x3520
        []  tcp_write_xmit+0xd64/0x5fe0
        []  __tcp_push_pending_frames+0x8c/0x320
        []  tcp_sendmsg_locked+0x2245/0x3500
        []  tcp_sendmsg+0x27/0x40
      
      As on the tx path of vxlan over esp, skb->inner_network_header would be
      set on vxlan_xmit() and xfrm4_tunnel_encap_add(), and the later one can
      overwrite the former one. It causes skb_udp_tunnel_segment() to use a
      wrong skb->inner_network_header, then the issue occurs.
      
      This patch is to fix it by calling xfrm_output_gso() instead when the
      inner_protocol is set, in which gso_segment of inner_protocol will be
      done first.
      
      While at it, also improve some code around.
      
      Fixes: 7862b405 ("esp: Add gso handlers for esp4 and esp6")
      Reported-by: default avatarXiumei Mu <xmu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      a204aef9
    • Xin Long's avatar
      esp4: support ipv6 nexthdrs process for beet gso segment · 6f297068
      Xin Long authored
      For beet mode, when it's ipv6 inner address with nexthdrs set,
      the packet format might be:
      
          ----------------------------------------------------
          | outer  |     | dest |     |      |  ESP    | ESP |
          | IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
          ----------------------------------------------------
      
      Before doing gso segment in xfrm4_beet_gso_segment(), the same
      thing is needed as it does in xfrm6_beet_gso_segment() in last
      patch 'esp6: support ipv6 nexthdrs process for beet gso segment'.
      
      v1->v2:
        - remove skb_transport_offset(), as it will always return 0
          in xfrm6_beet_gso_segment(), thank Sabrina's check.
      
      Fixes: 384a46ea ("esp4: add gso_segment for esp4 beet mode")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      6f297068
    • Xin Long's avatar
      esp6: support ipv6 nexthdrs process for beet gso segment · 25a44ae9
      Xin Long authored
      For beet mode, when it's ipv6 inner address with nexthdrs set,
      the packet format might be:
      
          ----------------------------------------------------
          | outer  |     | dest |     |      |  ESP    | ESP |
          | IP6 hdr| ESP | opts.| TCP | Data | Trailer | ICV |
          ----------------------------------------------------
      
      Before doing gso segment in xfrm6_beet_gso_segment(), it should
      skip all nexthdrs and get the real transport proto, and set
      transport_header properly.
      
      This patch is to fix it by simply calling ipv6_skip_exthdr()
      in xfrm6_beet_gso_segment().
      
      v1->v2:
        - remove skb_transport_offset(), as it will always return 0
          in xfrm6_beet_gso_segment(), thank Sabrina's check.
      
      Fixes: 7f9e40eb ("esp6: add gso_segment for esp6 beet mode")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      25a44ae9
  3. 20 Apr, 2020 3 commits
  4. 15 Apr, 2020 3 commits
    • Xin Long's avatar
      esp6: get the right proto for transport mode in esp6_gso_encap · 3c96ec56
      Xin Long authored
      For transport mode, when ipv6 nexthdr is set, the packet format might
      be like:
      
          ----------------------------------------------------
          |        | dest |     |     |      |  ESP    | ESP |
          | IP6 hdr| opts.| ESP | TCP | Data | Trailer | ICV |
          ----------------------------------------------------
      
      What it wants to get for x-proto in esp6_gso_encap() is the proto that
      will be set in ESP nexthdr. So it should skip all ipv6 nexthdrs and
      get the real transport protocol. Othersize, the wrong proto number
      will be set into ESP nexthdr.
      
      This patch is to skip all ipv6 nexthdrs by calling ipv6_skip_exthdr()
      in esp6_gso_encap().
      
      Fixes: 7862b405 ("esp: Add gso handlers for esp4 and esp6")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      3c96ec56
    • Xin Long's avatar
      xfrm: do pskb_pull properly in __xfrm_transport_prep · 06a0afcf
      Xin Long authored
      For transport mode, when ipv6 nexthdr is set, the packet format might
      be like:
      
          ----------------------------------------------------
          |        | dest |     |     |      |  ESP    | ESP |
          | IP6 hdr| opts.| ESP | TCP | Data | Trailer | ICV |
          ----------------------------------------------------
      
      and in __xfrm_transport_prep():
      
        pskb_pull(skb, skb->mac_len + sizeof(ip6hdr) + x->props.header_len);
      
      it will pull the data pointer to the wrong position, as it missed the
      nexthdrs/dest opts.
      
      This patch is to fix it by using:
      
        pskb_pull(skb, skb_transport_offset(skb) + x->props.header_len);
      
      as we can be sure transport_header points to ESP header at that moment.
      
      It also fixes a panic when packets with ipv6 nexthdr are sent over
      esp6 transport mode:
      
        [  100.473845] kernel BUG at net/core/skbuff.c:4325!
        [  100.478517] RIP: 0010:__skb_to_sgvec+0x252/0x260
        [  100.494355] Call Trace:
        [  100.494829]  skb_to_sgvec+0x11/0x40
        [  100.495492]  esp6_output_tail+0x12e/0x550 [esp6]
        [  100.496358]  esp6_xmit+0x1d5/0x260 [esp6_offload]
        [  100.498029]  validate_xmit_xfrm+0x22f/0x2e0
        [  100.499604]  __dev_queue_xmit+0x589/0x910
        [  100.502928]  ip6_finish_output2+0x2a5/0x5a0
        [  100.503718]  ip6_output+0x6c/0x120
        [  100.505198]  xfrm_output_resume+0x4bf/0x530
        [  100.508683]  xfrm6_output+0x3a/0xc0
        [  100.513446]  inet6_csk_xmit+0xa1/0xf0
        [  100.517335]  tcp_sendmsg+0x27/0x40
        [  100.517977]  sock_sendmsg+0x3e/0x60
        [  100.518648]  __sys_sendto+0xee/0x160
      
      Fixes: c35fe410 ("xfrm: Add mode handlers for IPsec on layer 2")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      06a0afcf
    • Xin Long's avatar
      xfrm: allow to accept packets with ipv6 NEXTHDR_HOP in xfrm_input · afcaf61b
      Xin Long authored
      For beet mode, when it's ipv6 inner address with nexthdrs set,
      the packet format might be:
      
          ----------------------------------------------------
          | outer  |     | dest |     |      |  ESP    | ESP |
          | IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
          ----------------------------------------------------
      
      The nexthdr from ESP could be NEXTHDR_HOP(0), so it should
      continue processing the packet when nexthdr returns 0 in
      xfrm_input(). Otherwise, when ipv6 nexthdr is set, the
      packet will be dropped.
      
      I don't see any error cases that nexthdr may return 0. So
      fix it by removing the check for nexthdr == 0.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      afcaf61b
  5. 14 Apr, 2020 15 commits
  6. 13 Apr, 2020 3 commits
  7. 12 Apr, 2020 3 commits
  8. 11 Apr, 2020 3 commits
  9. 10 Apr, 2020 1 commit
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 40fc7ad2
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2020-04-10
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 13 non-merge commits during the last 7 day(s) which contain
      a total of 13 files changed, 137 insertions(+), 43 deletions(-).
      
      The main changes are:
      
      1) JIT code emission fixes for riscv and arm32, from Luke Nelson and Xi Wang.
      
      2) Disable vmlinux BTF info if GCC_PLUGIN_RANDSTRUCT is used, from Slava Bacherikov.
      
      3) Fix oob write in AF_XDP when meta data is used, from Li RongQing.
      
      4) Fix bpf_get_link_xdp_id() handling on single prog when flags are specified,
         from Andrey Ignatov.
      
      5) Fix sk_assign() BPF helper for request sockets that can have sk_reuseport
         field uninitialized, from Joe Stringer.
      
      6) Fix mprotect() test case for the BPF LSM, from KP Singh.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40fc7ad2
  10. 09 Apr, 2020 5 commits
    • Taras Chornyi's avatar
      net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin · 690cc863
      Taras Chornyi authored
      When CONFIG_IP_MULTICAST is not set and multicast ip is added to the device
      with autojoin flag or when multicast ip is deleted kernel will crash.
      
      steps to reproduce:
      
      ip addr add 224.0.0.0/32 dev eth0
      ip addr del 224.0.0.0/32 dev eth0
      
      or
      
      ip addr add 224.0.0.0/32 dev eth0 autojoin
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
       pc : _raw_write_lock_irqsave+0x1e0/0x2ac
       lr : lock_sock_nested+0x1c/0x60
       Call trace:
        _raw_write_lock_irqsave+0x1e0/0x2ac
        lock_sock_nested+0x1c/0x60
        ip_mc_config.isra.28+0x50/0xe0
        inet_rtm_deladdr+0x1a8/0x1f0
        rtnetlink_rcv_msg+0x120/0x350
        netlink_rcv_skb+0x58/0x120
        rtnetlink_rcv+0x14/0x20
        netlink_unicast+0x1b8/0x270
        netlink_sendmsg+0x1a0/0x3b0
        ____sys_sendmsg+0x248/0x290
        ___sys_sendmsg+0x80/0xc0
        __sys_sendmsg+0x68/0xc0
        __arm64_sys_sendmsg+0x20/0x30
        el0_svc_common.constprop.2+0x88/0x150
        do_el0_svc+0x20/0x80
       el0_sync_handler+0x118/0x190
        el0_sync+0x140/0x180
      
      Fixes: 93a714d6 ("multicast: Extend ip address command to enable multicast group join/leave on")
      Signed-off-by: default avatarTaras Chornyi <taras.chornyi@plvision.eu>
      Signed-off-by: default avatarVadym Kochan <vadym.kochan@plvision.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      690cc863
    • Ka-Cheong Poon's avatar
      net/rds: Fix MR reference counting problem · 2fabef4f
      Ka-Cheong Poon authored
      In rds_free_mr(), it calls rds_destroy_mr(mr) directly.  But this
      defeats the purpose of reference counting and makes MR free handling
      impossible.  It means that holding a reference does not guarantee that
      it is safe to access some fields.  For example, In
      rds_cmsg_rdma_dest(), it increases the ref count, unlocks and then
      calls mr->r_trans->sync_mr().  But if rds_free_mr() (and
      rds_destroy_mr()) is called in between (there is no lock preventing
      this to happen), r_trans_private is set to NULL, causing a panic.
      Similar issue is in rds_rdma_unuse().
      Reported-by: default avatarzerons <sironhide0null@gmail.com>
      Signed-off-by: default avatarKa-Cheong Poon <ka-cheong.poon@oracle.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fabef4f
    • Ka-Cheong Poon's avatar
    • Taehee Yoo's avatar
      net: macsec: fix using wrong structure in macsec_changelink() · 022e9d60
      Taehee Yoo authored
      In the macsec_changelink(), "struct macsec_tx_sa tx_sc" is used to
      store "macsec_secy.tx_sc".
      But, the struct type of tx_sc is macsec_tx_sc, not macsec_tx_sa.
      So, the macsec_tx_sc should be used instead.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add macsec0 link dummy0 type macsec
          ip link set macsec0 type macsec encrypt off
      
      Splat looks like:
      [61119.963483][ T9335] ==================================================================
      [61119.964709][ T9335] BUG: KASAN: slab-out-of-bounds in macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.965787][ T9335] Read of size 160 at addr ffff888020d69c68 by task ip/9335
      [61119.966699][ T9335]
      [61119.966979][ T9335] CPU: 0 PID: 9335 Comm: ip Not tainted 5.6.0+ #503
      [61119.967791][ T9335] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [61119.968914][ T9335] Call Trace:
      [61119.969324][ T9335]  dump_stack+0x96/0xdb
      [61119.969809][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.970554][ T9335]  print_address_description.constprop.5+0x1be/0x360
      [61119.971294][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.971973][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.972703][ T9335]  __kasan_report+0x12a/0x170
      [61119.973323][ T9335]  ? macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.973942][ T9335]  kasan_report+0xe/0x20
      [61119.974397][ T9335]  check_memory_region+0x149/0x1a0
      [61119.974866][ T9335]  memcpy+0x1f/0x50
      [61119.975209][ T9335]  macsec_changelink.part.34+0xb6/0x200 [macsec]
      [61119.975825][ T9335]  ? macsec_get_stats64+0x3e0/0x3e0 [macsec]
      [61119.976451][ T9335]  ? kernel_text_address+0x111/0x120
      [61119.976990][ T9335]  ? pskb_expand_head+0x25f/0xe10
      [61119.977503][ T9335]  ? stack_trace_save+0x82/0xb0
      [61119.977986][ T9335]  ? memset+0x1f/0x40
      [61119.978397][ T9335]  ? __nla_validate_parse+0x98/0x1ab0
      [61119.978936][ T9335]  ? macsec_alloc_tfm+0x90/0x90 [macsec]
      [61119.979511][ T9335]  ? __kasan_slab_free+0x111/0x150
      [61119.980021][ T9335]  ? kfree+0xce/0x2f0
      [61119.980700][ T9335]  ? netlink_trim+0x196/0x1f0
      [61119.981420][ T9335]  ? nla_memcpy+0x90/0x90
      [61119.982036][ T9335]  ? register_lock_class+0x19e0/0x19e0
      [61119.982776][ T9335]  ? memcpy+0x34/0x50
      [61119.983327][ T9335]  __rtnl_newlink+0x922/0x1270
      [ ... ]
      
      Fixes: 3cf3227a ("net: macsec: hardware offloading infrastructure")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      022e9d60
    • Colin Ian King's avatar
      net-sysfs: remove redundant assignment to variable ret · 5f0224a6
      Colin Ian King authored
      The variable ret is being initialized with a value that is never read
      and it is being updated later with a new value.  The initialization is
      redundant and can be removed.
      
      Addresses-Coverity: ("Unused value")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f0224a6