1. 30 Aug, 2018 18 commits
    • Paolo Abeni's avatar
      net_sched: reject unknown tcfa_action values · 97763dc0
      Paolo Abeni authored
      After the commit 802bfb19 ("net/sched: user-space can't set
      unknown tcfa_action values"), unknown tcfa_action values are
      converted to TC_ACT_UNSPEC, but the common agreement is instead
      rejecting such configurations.
      
      This change also introduces a helper to simplify the destruction
      of a single action, avoiding code duplication.
      
      v1 -> v2:
       - helper is now static and renamed according to act_* convention
       - updated extack message, according to the new behavior
      
      Fixes: 802bfb19 ("net/sched: user-space can't set unknown tcfa_action values")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97763dc0
    • Baruch Siach's avatar
      net: mvpp2: initialize port of_node pointer · c4053ef3
      Baruch Siach authored
      Without a valid of_node in struct device we can't find the mvpp2 port
      device by its DT node. Specifically, this breaks
      of_find_net_device_by_node().
      
      For example, the Armada 8040 based Clearfog GT-8K uses Marvell 88E6141
      switch connected to the &cp1_eth2 port:
      
      &cp1_mdio {
      	...
      
      	switch0: switch0@4 {
      		compatible = "marvell,mv88e6085";
      		...
      
      		ports {
      			...
      
      			port@5 {
      				reg = <5>;
      				label = "cpu";
      				ethernet = <&cp1_eth2>;
      			};
      		};
      	};
      };
      
      Without this patch, dsa_register_switch() returns -EPROBE_DEFER because
      of_find_net_device_by_node() can't find the device_node of the &cp1_eth2
      device.
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4053ef3
    • Doug Berger's avatar
      net: bcmgenet: use MAC link status for fixed phy · c3c397c1
      Doug Berger authored
      When using the fixed PHY with GENET (e.g. MOCA) the PHY link
      status can be determined from the internal link status captured
      by the MAC. This allows the PHY state machine to use the correct
      link state with the fixed PHY even if MAC link event interrupts
      are missed when the net device is opened.
      
      Fixes: 8d88c6eb ("net: bcmgenet: enable MoCA link state change detection")
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3c397c1
    • Dinh Nguyen's avatar
      net: stmmac: build the dwmac-socfpga platform driver for Stratix10 · c305660b
      Dinh Nguyen authored
      The Stratix10 SoC is an AARCH64 based platform that shares the same ethernet
      controller that is on other SoCFPGA platforms. Build the platform driver.
      Signed-off-by: default avatarDinh Nguyen <dinguyen@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c305660b
    • David S. Miller's avatar
      Merge branch 'ipv6-fix-error-path-of-inet6_init' · e0b7e7dc
      David S. Miller authored
      Sabrina Dubroca says:
      
      ====================
      ipv6: fix error path of inet6_init()
      
      The error path of inet6_init() can trigger multiple kernel panics,
      mostly due to wrong ordering of cleanups. This series fixes those
      issues.
      ====================
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0b7e7dc
    • Sabrina Dubroca's avatar
      net: rtnl: return early from rtnl_unregister_all when protocol isn't registered · f707ef61
      Sabrina Dubroca authored
      rtnl_unregister_all(PF_INET6) gets called from inet6_init in cases when
      no handler has been registered for PF_INET6 yet, for example if
      ip6_mr_init() fails. Abort and avoid a NULL pointer deref in that case.
      
      Example of panic (triggered by faking a failure of
       register_pernet_subsys):
      
          general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
          [...]
          RIP: 0010:rtnl_unregister_all+0x17e/0x2a0
          [...]
          Call Trace:
           ? rtnetlink_net_init+0x250/0x250
           ? sock_unregister+0x103/0x160
           ? kernel_getsockopt+0x200/0x200
           inet6_init+0x197/0x20d
      
      Fixes: e2fddf5e ("[IPV6]: Make af_inet6 to check ip6_route_init return value.")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f707ef61
    • Sabrina Dubroca's avatar
      ipv6: fix cleanup ordering for pingv6 registration · a03dc36b
      Sabrina Dubroca authored
      Commit 6d0bfe22 ("net: ipv6: Add IPv6 support to the ping socket.")
      contains an error in the cleanup path of inet6_init(): when
      proto_register(&pingv6_prot, 1) fails, we try to unregister
      &pingv6_prot. When rawv6_init() fails, we skip unregistering
      &pingv6_prot.
      
      Example of panic (triggered by faking a failure of
       proto_register(&pingv6_prot, 1)):
      
          general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
          [...]
          RIP: 0010:__list_del_entry_valid+0x79/0x160
          [...]
          Call Trace:
           proto_unregister+0xbb/0x550
           ? trace_preempt_on+0x6f0/0x6f0
           ? sock_no_shutdown+0x10/0x10
           inet6_init+0x153/0x1b8
      
      Fixes: 6d0bfe22 ("net: ipv6: Add IPv6 support to the ping socket.")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a03dc36b
    • Sabrina Dubroca's avatar
      ipv6: fix cleanup ordering for ip6_mr failure · afe49de4
      Sabrina Dubroca authored
      Commit 15e66807 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
      moved the cleanup label for ipmr_fail, but should have changed the
      contents of the cleanup labels as well. Now we can end up cleaning up
      icmpv6 even though it hasn't been initialized (jump to icmp_fail or
      ipmr_fail).
      
      Simply undo things in the reverse order of their initialization.
      
      Example of panic (triggered by faking a failure of icmpv6_init):
      
          kasan: GPF could be caused by NULL-ptr deref or user memory access
          general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
          [...]
          RIP: 0010:__list_del_entry_valid+0x79/0x160
          [...]
          Call Trace:
           ? lock_release+0x8a0/0x8a0
           unregister_pernet_operations+0xd4/0x560
           ? ops_free_list+0x480/0x480
           ? down_write+0x91/0x130
           ? unregister_pernet_subsys+0x15/0x30
           ? down_read+0x1b0/0x1b0
           ? up_read+0x110/0x110
           ? kmem_cache_create_usercopy+0x1b4/0x240
           unregister_pernet_subsys+0x1d/0x30
           icmpv6_cleanup+0x1d/0x30
           inet6_init+0x1b5/0x23f
      
      Fixes: 15e66807 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afe49de4
    • Davide Caratti's avatar
      net/sched: act_pedit: fix dump of extended layered op · 85eb9af1
      Davide Caratti authored
      in the (rare) case of failure in nla_nest_start(), missing NULL checks in
      tcf_pedit_key_ex_dump() can make the following command
      
       # tc action add action pedit ex munge ip ttl set 64
      
      dereference a NULL pointer:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       PGD 800000007d1cd067 P4D 800000007d1cd067 PUD 7acd3067 PMD 0
       Oops: 0002 [#1] SMP PTI
       CPU: 0 PID: 3336 Comm: tc Tainted: G            E     4.18.0.pedit+ #425
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_pedit_dump+0x19d/0x358 [act_pedit]
       Code: be 02 00 00 00 48 89 df 66 89 44 24 20 e8 9b b1 fd e0 85 c0 75 46 8b 83 c8 00 00 00 49 83 c5 08 48 03 83 d0 00 00 00 4d 39 f5 <66> 89 04 25 00 00 00 00 0f 84 81 01 00 00 41 8b 45 00 48 8d 4c 24
       RSP: 0018:ffffb5d4004478a8 EFLAGS: 00010246
       RAX: ffff8880fcda2070 RBX: ffff8880fadd2900 RCX: 0000000000000000
       RDX: 0000000000000002 RSI: ffffb5d4004478ca RDI: ffff8880fcda206e
       RBP: ffff8880fb9cb900 R08: 0000000000000008 R09: ffff8880fcda206e
       R10: ffff8880fadd2900 R11: 0000000000000000 R12: ffff8880fd26cf40
       R13: ffff8880fc957430 R14: ffff8880fc957430 R15: ffff8880fb9cb988
       FS:  00007f75a537a740(0000) GS:ffff8880fda00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000007a2fa005 CR4: 00000000001606f0
       Call Trace:
        ? __nla_reserve+0x38/0x50
        tcf_action_dump_1+0xd2/0x130
        tcf_action_dump+0x6a/0xf0
        tca_get_fill.constprop.31+0xa3/0x120
        tcf_action_add+0xd1/0x170
        tc_ctl_action+0x137/0x150
        rtnetlink_rcv_msg+0x263/0x2d0
        ? _cond_resched+0x15/0x40
        ? rtnl_calcit.isra.30+0x110/0x110
        netlink_rcv_skb+0x4d/0x130
        netlink_unicast+0x1a3/0x250
        netlink_sendmsg+0x2ae/0x3a0
        sock_sendmsg+0x36/0x40
        ___sys_sendmsg+0x26f/0x2d0
        ? do_wp_page+0x8e/0x5f0
        ? handle_pte_fault+0x6c3/0xf50
        ? __handle_mm_fault+0x38e/0x520
        ? __sys_sendmsg+0x5e/0xa0
        __sys_sendmsg+0x5e/0xa0
        do_syscall_64+0x5b/0x180
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7f75a4583ba0
       Code: c3 48 8b 05 f2 62 2c 00 f7 db 64 89 18 48 83 cb ff eb dd 0f 1f 80 00 00 00 00 83 3d fd c3 2c 00 00 75 10 b8 2e 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ae cc 00 00 48 89 04 24
       RSP: 002b:00007fff60ee7418 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
       RAX: ffffffffffffffda RBX: 00007fff60ee7540 RCX: 00007f75a4583ba0
       RDX: 0000000000000000 RSI: 00007fff60ee7490 RDI: 0000000000000003
       RBP: 000000005b842d3e R08: 0000000000000002 R09: 0000000000000000
       R10: 00007fff60ee6ea0 R11: 0000000000000246 R12: 0000000000000000
       R13: 00007fff60ee7554 R14: 0000000000000001 R15: 000000000066c100
       Modules linked in: act_pedit(E) ip6table_filter ip6_tables iptable_filter binfmt_misc crct10dif_pclmul ext4 crc32_pclmul mbcache ghash_clmulni_intel jbd2 pcbc snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd snd_timer cryptd glue_helper snd joydev pcspkr soundcore virtio_balloon i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net net_failover virtio_blk virtio_console failover qxl crc32c_intel drm_kms_helper syscopyarea serio_raw sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix virtio_pci libata virtio_ring i2c_core virtio floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_pedit]
       CR2: 0000000000000000
      
      Like it's done for other TC actions, give up dumping pedit rules and return
      an error if nla_nest_start() returns NULL.
      
      Fixes: 71d0ed70 ("net/act_pedit: Support using offset relative to the conventional network headers")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85eb9af1
    • Chris Brandt's avatar
      sh_eth: Add R7S9210 support · 6e0bb04d
      Chris Brandt authored
      Add support for the R7S9210 which is part of the RZ/A2 series.
      Signed-off-by: default avatarChris Brandt <chris.brandt@renesas.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e0bb04d
    • David S. Miller's avatar
      Merge branch 'hns-fixes' · def70b61
      David S. Miller authored
      Peng Li says:
      
      ====================
      net: hns: fix some bugs about speed and duplex change
      
      If there are packets in hardware when changing the spped
      or duplex, it may cause hardware hang up.
      
      This patchset adds the code for waiting chip to clean the all
      pkts(TX & RX) in chip when the driver uses the function named
      "adjust link".
      
      This patchset cleans the pkts as follows:
      1) close rx of chip, close tx of protocol stack.
      2) wait rcb, ppe, mac to clean.
      3) adjust link
      4) open rx of chip, open tx of protocol stack.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      def70b61
    • Peng Li's avatar
      net: hns: add netif_carrier_off before change speed and duplex · 455c4401
      Peng Li authored
      If there are packets in hardware when changing the speed
      or duplex, it may cause hardware hang up.
      
      This patch adds netif_carrier_off before change speed and
      duplex in ethtool_ops.set_link_ksettings, and adds
      netif_carrier_on after complete the change.
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      455c4401
    • Peng Li's avatar
      net: hns: add the code for cleaning pkt in chip · 31fabbee
      Peng Li authored
      If there are packets in hardware when changing the speed
      or duplex, it may cause hardware hang up.
      
      This patch adds the code for waiting chip to clean the all
      pkts(TX & RX) in chip when the driver uses the function named
      "adjust link".
      
      This patch cleans the pkts as follows:
      1) close rx of chip, close tx of protocol stack.
      2) wait rcb, ppe, mac to clean.
      3) adjust link
      4) open rx of chip, open tx of protocol stack.
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31fabbee
    • Azat Khuzhin's avatar
      r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices · 05212ba8
      Azat Khuzhin authored
      I have two Ethernet adapters:
        r8169 0000:03:01.0 eth0: RTL8169sb/8110sb, 00:14:d1:14:2d:49, XID 10000000, IRQ 18
        r8169 0000:01:00.0 eth0: RTL8168e/8111e, 64:66:b3:11:14:5d, XID 2c200000, IRQ 30
      And after upgrading from linux 4.15 [1] to linux 4.18+ [2] RTL8169sb failed to
      receive any packets. tcpdump shows a lot of checksum mismatch.
      
        [1]: a0f79386
        [2]: 05193597 (4.19 merge window opened)
      
      I started bisecting and the found that [3] breaks it. According to [4]:
        "For 8110S, 8110SB, and 8110SC series, the initial value of RxConfig
        needs to be set after the tx/rx is enabled."
      So I moved rtl_init_rxcfg() after enabling tx/rs and now my adapter works
      (RTL8168e works too).
      
        [3]: 3559d81e
        [4]: e542a226 ("r8169: adjust the RxConfig
      settings.")
      
      Also drop "rx" from rtl_set_rx_tx_config_registers(), since it does nothing
      with it already.
      
      Fixes: 3559d81e ("r8169: simplify
      rtl_hw_start_8169")
      
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      Signed-off-by: default avatarAzat Khuzhin <a3at.mail@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05212ba8
    • Cong Wang's avatar
      tipc: switch to rhashtable iterator · 9a07efa9
      Cong Wang authored
      syzbot reported a use-after-free in tipc_group_fill_sock_diag(),
      where tipc_group_fill_sock_diag() still reads tsk->group meanwhile
      tipc_group_delete() just deletes it in tipc_release().
      
      tipc_nl_sk_walk() aims to lock this sock when walking each sock
      in the hash table to close race conditions with sock changes like
      this one, by acquiring tsk->sk.sk_lock.slock spinlock, unfortunately
      this doesn't work at all. All non-BH call path should take
      lock_sock() instead to make it work.
      
      tipc_nl_sk_walk() brutally iterates with raw rht_for_each_entry_rcu()
      where RCU read lock is required, this is the reason why lock_sock()
      can't be taken on this path. This could be resolved by switching to
      rhashtable iterator API's, where taking a sleepable lock is possible.
      Also, the iterator API's are friendly for restartable calls like
      diag dump, the last position is remembered behind the scence,
      all we need to do here is saving the iterator into cb->args[].
      
      I tested this with parallel tipc diag dump and thousands of tipc
      socket creation and release, no crash or memory leak.
      
      Reported-by: syzbot+b9c8f3ab2994b7cd1625@syzkaller.appspotmail.com
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a07efa9
    • Jerome Brunet's avatar
      Revert "net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit" · e5133f2f
      Jerome Brunet authored
      This reverts commit 4ae0169f.
      
      This change in the handling of the coalesce timer is causing regression on
      (at least) amlogic platforms.
      
      Network will break down very quickly (a few seconds) after starting
      a download. This can easily be reproduced using iperf3 for example.
      
      The problem has been reported on the S805, S905, S912 and A113 SoCs
      (Realtek and Micrel PHYs) and it is likely impacting all Amlogics
      platforms using Gbit ethernet
      
      No problem was seen with the platform using 10/100 only PHYs (GXL internal)
      
      Reverting change brings things back to normal and allows to use network
      again until we better understand the problem with the coalesce timer.
      
      Cc: Jose Abreu <joabreu@synopsys.com>
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: Vitor Soares <soares@synopsys.com>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Cc: Corentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5133f2f
    • Cong Wang's avatar
      tipc: fix a missing rhashtable_walk_exit() · bd583fe3
      Cong Wang authored
      rhashtable_walk_exit() must be paired with rhashtable_walk_enter().
      
      Fixes: 40f9f439 ("tipc: Fix tipc_sk_reinit race conditions")
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd583fe3
    • Alexey Kodanev's avatar
      vti6: remove !skb->ignore_df check from vti6_xmit() · 9f289546
      Alexey Kodanev authored
      Before the commit d6990976 ("vti6: fix PMTU caching and reporting
      on xmit") '!skb->ignore_df' check was always true because the function
      skb_scrub_packet() was called before it, resetting ignore_df to zero.
      
      In the commit, skb_scrub_packet() was moved below, and now this check
      can be false for the packet, e.g. when sending it in the two fragments,
      this prevents successful PMTU updates in such case. The next attempts
      to send the packet lead to the same tx error. Moreover, vti6 initial
      MTU value relies on PMTU adjustments.
      
      This issue can be reproduced with the following LTP test script:
          udp_ipsec_vti.sh -6 -p ah -m tunnel -s 2000
      
      Fixes: ccd740cb ("vti6: Add pmtu handling to vti6_xmit.")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Acked-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f289546
  2. 29 Aug, 2018 6 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 6a5d39aa
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2018-08-29
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) Fix a build error in sk_reuseport_convert_ctx_access() when
         compiling with clang which cannot resolve hweight_long() at
         build time inside the BUILD_BUG_ON() assertion, from Stefan.
      
      2) Several fixes for BPF sockmap, four of them in getting the
         bpf_msg_pull_data() helper to work, one use after free case
         in bpf_tcp_close() and one refcount leak in bpf_tcp_recvmsg(),
         from Daniel.
      
      3) Another fix for BPF sockmap where we misaccount sk_mem_uncharge()
         in the socket redirect error case from unwinding scatterlist
         twice, from John.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a5d39aa
    • Alexei Starovoitov's avatar
      Merge branch 'bpf_msg_pull_data-fixes' · d65e6c80
      Alexei Starovoitov authored
      Daniel Borkmann says:
      
      ====================
      This set contains three more fixes for the bpf_msg_pull_data()
      mainly for correcting scatterlist ring wrap-arounds as well as
      fixing up data pointers. For details please see individual patches.
      Thanks!
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      d65e6c80
    • Daniel Borkmann's avatar
      bpf: fix sg shift repair start offset in bpf_msg_pull_data · a8cf76a9
      Daniel Borkmann authored
      When we perform the sg shift repair for the scatterlist ring, we
      currently start out at i = first_sg + 1. However, this is not
      correct since the first_sg could point to the sge sitting at slot
      MAX_SKB_FRAGS - 1, and a subsequent i = MAX_SKB_FRAGS will access
      the scatterlist ring (sg) out of bounds. Add the sk_msg_iter_var()
      helper for iterating through the ring, and apply the same rule
      for advancing to the next ring element as we do elsewhere. Later
      work will use this helper also in other places.
      
      Fixes: 015632bb ("bpf: sk_msg program helper bpf_sk_msg_pull_data")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      a8cf76a9
    • Daniel Borkmann's avatar
      bpf: fix shift upon scatterlist ring wrap-around in bpf_msg_pull_data · 2e43f95d
      Daniel Borkmann authored
      If first_sg and last_sg wraps around in the scatterlist ring, then we
      need to account for that in the shift as well. E.g. crafting such msgs
      where this is the case leads to a hang as shift becomes negative. E.g.
      consider the following scenario:
      
        first_sg := 14     |=>    shift := -12     msg->sg_start := 10
        last_sg  :=  3     |                       msg->sg_end   :=  5
      
      round  1:  i := 15, move_from :=   3, sg[15] := sg[  3]
      round  2:  i :=  0, move_from := -12, sg[ 0] := sg[-12]
      round  3:  i :=  1, move_from := -11, sg[ 1] := sg[-11]
      round  4:  i :=  2, move_from := -10, sg[ 2] := sg[-10]
      [...]
      round 13:  i := 11, move_from :=  -1, sg[ 2] := sg[ -1]
      round 14:  i := 12, move_from :=   0, sg[ 2] := sg[  0]
      round 15:  i := 13, move_from :=   1, sg[ 2] := sg[  1]
      round 16:  i := 14, move_from :=   2, sg[ 2] := sg[  2]
      round 17:  i := 15, move_from :=   3, sg[ 2] := sg[  3]
      [...]
      
      This means we will loop forever and never hit the msg->sg_end condition
      to break out of the loop. When we see that the ring wraps around, then
      the shift should be MAX_SKB_FRAGS - first_sg + last_sg - 1. Meaning,
      the remainder slots from the tail of the ring and the head until last_sg
      combined.
      
      Fixes: 015632bb ("bpf: sk_msg program helper bpf_sk_msg_pull_data")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2e43f95d
    • Daniel Borkmann's avatar
      bpf: fix msg->data/data_end after sg shift repair in bpf_msg_pull_data · 0e06b227
      Daniel Borkmann authored
      In the current code, msg->data is set as sg_virt(&sg[i]) + start - offset
      and msg->data_end relative to it as msg->data + bytes. Using iterator i
      to point to the updated starting scatterlist element holds true for some
      cases, however not for all where we'd end up pointing out of bounds. It
      is /correct/ for these ones:
      
      1) When first finding the starting scatterlist element (sge) where we
         find that the page is already privately owned by the msg and where
         the requested bytes and headroom fit into the sge's length.
      
      However, it's /incorrect/ for the following ones:
      
      2) After we made the requested area private and updated the newly allocated
         page into first_sg slot of the scatterlist ring; when we find that no
         shift repair of the ring is needed where we bail out updating msg->data
         and msg->data_end. At that point i will point to last_sg, which in this
         case is the next elem of first_sg in the ring. The sge at that point
         might as well be invalid (e.g. i == msg->sg_end), which we use for
         setting the range of sg_virt(&sg[i]). The correct one would have been
         first_sg.
      
      3) Similar as in 2) but when we find that a shift repair of the ring is
         needed. In this case we fix up all sges and stop once we've reached the
         end. In this case i will point to will point to the new msg->sg_end,
         and the sge at that point will be invalid. Again here the requested
         range sits in first_sg.
      
      Fixes: 015632bb ("bpf: sk_msg program helper bpf_sk_msg_pull_data")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      0e06b227
    • Daniel Borkmann's avatar
      bpf: fix several offset tests in bpf_msg_pull_data · 5b24109b
      Daniel Borkmann authored
      While recently going over bpf_msg_pull_data(), I noticed three
      issues which are fixed in here:
      
      1) When we attempt to find the first scatterlist element (sge)
         for the start offset, we add len to the offset before we check
         for start < offset + len, whereas it should come after when
         we iterate to the next sge to accumulate the offsets. For
         example, given a start offset of 12 with a sge length of 8
         for the first sge in the list would lead us to determine this
         sge as the first sge thinking it covers first 16 bytes where
         start is located, whereas start sits in subsequent sges so
         we would end up pulling in the wrong data.
      
      2) After figuring out the starting sge, we have a short-cut test
         in !msg->sg_copy[i] && bytes <= len. This checks whether it's
         not needed to make the page at the sge private where we can
         just exit by updating msg->data and msg->data_end. However,
         the length test is not fully correct. bytes <= len checks
         whether the requested bytes (end - start offsets) fit into the
         sge's length. The part that is missing is that start must not
         be sge length aligned. Meaning, the start offset into the sge
         needs to be accounted as well on top of the requested bytes
         as otherwise we can access the sge out of bounds. For example
         the sge could have length of 8, our requested bytes could have
         length of 8, but at a start offset of 4, so we also would need
         to pull in 4 bytes of the next sge, when we jump to the out
         label we do set msg->data to sg_virt(&sg[i]) + start - offset
         and msg->data_end to msg->data + bytes which would be oob.
      
      3) The subsequent bytes < copy test for finding the last sge has
         the same issue as in point 2) but also it tests for less than
         rather than less or equal to. Meaning if the sge length is of
         8 and requested bytes of 8 while having the start aligned with
         the sge, we would unnecessarily go and pull in the next sge as
         well to make it private.
      
      Fixes: 015632bb ("bpf: sk_msg program helper bpf_sk_msg_pull_data")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      5b24109b
  3. 28 Aug, 2018 4 commits
    • John Fastabend's avatar
      bpf: sockmap, decrement copied count correctly in redirect error case · 501ca817
      John Fastabend authored
      Currently, when a redirect occurs in sockmap and an error occurs in
      the redirect call we unwind the scatterlist once in the error path
      of bpf_tcp_sendmsg_do_redirect() and then again in sendmsg(). Then
      in the error path of sendmsg we decrement the copied count by the
      send size.
      
      However, its possible we partially sent data before the error was
      generated. This can happen if do_tcp_sendpages() partially sends the
      scatterlist before encountering a memory pressure error. If this
      happens we need to decrement the copied value (the value tracking
      how many bytes were actually sent to TCP stack) by the number of
      remaining bytes _not_ the entire send size. Otherwise we risk
      confusing userspace.
      
      Also we don't need two calls to free the scatterlist one is
      good enough. So remove the one in bpf_tcp_sendmsg_do_redirect() and
      then properly reduce copied by the number of remaining bytes which
      may in fact be the entire send size if no bytes were sent.
      
      To do this use bool to indicate if free_start_sg() should do mem
      accounting or not.
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      501ca817
    • Stefan Agner's avatar
      bpf: fix build error with clang · 3f6e138d
      Stefan Agner authored
      Building the newly introduced BPF_PROG_TYPE_SK_REUSEPORT leads to
      a compile time error when building with clang:
      net/core/filter.o: In function `sk_reuseport_convert_ctx_access':
        ../net/core/filter.c:7284: undefined reference to `__compiletime_assert_7284'
      
      It seems that clang has issues resolving hweight_long at compile
      time. Since SK_FL_PROTO_MASK is a constant, we can use the interface
      for known constant arguments which works fine with clang.
      
      Fixes: 2dbb9b9e ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT")
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      3f6e138d
    • Daniel Borkmann's avatar
      bpf, sockmap: fix psock refcount leak in bpf_tcp_recvmsg · 15c480ef
      Daniel Borkmann authored
      In bpf_tcp_recvmsg() we first took a reference on the psock, however
      once we find that there are skbs in the normal socket's receive queue
      we return with processing them through tcp_recvmsg(). Problem is that
      we leak the taken reference on the psock in that path. Given we don't
      really do anything with the psock at this point, move the skb_queue_empty()
      test before we fetch the psock to fix this case.
      
      Fixes: 8934ce2f ("bpf: sockmap redirect ingress support")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      15c480ef
    • Daniel Borkmann's avatar
      bpf, sockmap: fix potential use after free in bpf_tcp_close · e06fa9c1
      Daniel Borkmann authored
      bpf_tcp_close() we pop the psock linkage to a map via psock_map_pop().
      A parallel update on the sock hash map can happen between psock_map_pop()
      and lookup_elem_raw() where we override the element under link->hash /
      link->key. In bpf_tcp_close()'s lookup_elem_raw() we subsequently only
      test whether an element is present, but we do not test whether the
      element is infact the element we were looking for.
      
      We lock the sock in bpf_tcp_close() during that time, so do we hold
      the lock in sock_hash_update_elem(). However, the latter locks the
      sock which is newly updated, not the one we're purging from the hash
      table. This means that while one CPU is doing the lookup from bpf_tcp_close(),
      another CPU is doing the map update in parallel, dropped our sock from
      the hlist and released the psock.
      
      Subsequently the first CPU will find the new sock and attempts to drop
      and release the old sock yet another time. Fix is that we need to check
      the elements for a match after lookup, similar as we do in the sock map.
      Note that the hash tab elems are freed via RCU, so access to their
      link->hash / link->key is fine since we're under RCU read side there.
      
      Fixes: e9db4ef6 ("bpf: sockhash fix omitted bucket lock in sock_close")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      e06fa9c1
  4. 27 Aug, 2018 11 commits
  5. 26 Aug, 2018 1 commit