1. 22 Oct, 2017 1 commit
    • Willem de Bruijn's avatar
      sock: correct sk_wmem_queued accounting on efault in tcp zerocopy · 54d43117
      Willem de Bruijn authored
      Syzkaller hits WARN_ON(sk->sk_wmem_queued) in sk_stream_kill_queues
      after triggering an EFAULT in __zerocopy_sg_from_iter.
      
      On this error, skb_zerocopy_stream_iter resets the skb to its state
      before the operation with __pskb_trim. It cannot kfree_skb like
      datagram callers, as the skb may have data from a previous send call.
      
      __pskb_trim calls skb_condense for unowned skbs, which adjusts their
      truesize. These tcp skbuffs are owned and their truesize must add up
      to sk_wmem_queued. But they match because their skb->sk is NULL until
      tcp_transmit_skb.
      
      Temporarily set skb->sk when calling __pskb_trim to signal that the
      skbuffs are owned and avoid the skb_condense path.
      
      Fixes: 52267790 ("sock: add MSG_ZEROCOPY")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54d43117
  2. 21 Oct, 2017 24 commits
    • David S. Miller's avatar
      Merge branch 'bpf-range-marking-fixes' · d2b27624
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      Two BPF fixes for range marking
      
      The set contains two fixes for direct packet access range
      markings and test cases for all direct packet access patterns
      that the verifier matches on.
      
      They are targeted for net tree, note that once net gets merged
      into net-next, there will be a minor merge conflict due to
      signature change of the function find_good_pkt_pointers() as
      well as data_meta patterns present in net-next tree. You can
      just add bool false to the data_meta patterns and I will
      follow-up with properly converting the patterns for data_meta
      in a similar way.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2b27624
    • Daniel Borkmann's avatar
      bpf: add test cases to bpf selftests to cover all access tests · b37242c7
      Daniel Borkmann authored
      Lets add test cases to cover really all possible direct packet
      access tests for good/bad access cases so we keep tracking them.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b37242c7
    • Daniel Borkmann's avatar
      bpf: fix pattern matches for direct packet access · 0fd4759c
      Daniel Borkmann authored
      Alexander had a test program with direct packet access, where
      the access test was in the form of data + X > data_end. In an
      unrelated change to the program LLVM decided to swap the branches
      and emitted code for the test in form of data + X <= data_end.
      We hadn't seen these being generated previously, thus verifier
      would reject the program. Therefore, fix up the verifier to
      detect all test cases, so we don't run into such issues in the
      future.
      
      Fixes: b4e432f1 ("bpf: enable BPF_J{LT, LE, SLT, SLE} opcodes in verifier")
      Reported-by: default avatarAlexander Alemayhu <alexander@alemayhu.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fd4759c
    • Daniel Borkmann's avatar
      bpf: fix off by one for range markings with L{T, E} patterns · fb2a311a
      Daniel Borkmann authored
      During review I noticed that the current logic for direct packet
      access marking in check_cond_jmp_op() has an off by one for the
      upper right range border when marking in find_good_pkt_pointers()
      with BPF_JLT and BPF_JLE. It's not really harmful given access
      up to pkt_end is always safe, but we should nevertheless correct
      the range marking before it becomes ABI. If pkt_data' denotes a
      pkt_data derived pointer (pkt_data + X), then for pkt_data' < pkt_end
      in the true branch as well as for pkt_end <= pkt_data' in the false
      branch we mark the range with X although it should really be X - 1
      in these cases. For example, X could be pkt_end - pkt_data, then
      when testing for pkt_data' < pkt_end the verifier simulation cannot
      deduce that a byte load of pkt_data' - 1 would succeed in this
      branch.
      
      Fixes: b4e432f1 ("bpf: enable BPF_J{LT, LE, SLT, SLE} opcodes in verifier")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb2a311a
    • John Fastabend's avatar
      bpf: devmap fix arithmetic overflow in bitmap_size calculation · 8695a539
      John Fastabend authored
      An integer overflow is possible in dev_map_bitmap_size() when
      calculating the BITS_TO_LONG logic which becomes, after macro
      replacement,
      
      	(((n) + (d) - 1)/ (d))
      
      where 'n' is a __u32 and 'd' is (8 * sizeof(long)). To avoid
      overflow cast to u64 before arithmetic.
      Reported-by: default avatarRichard Weinberger <richard@nod.at>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8695a539
    • David S. Miller's avatar
      Merge branch 'aquantia-fixes' · 43ebf97f
      David S. Miller authored
      Igor Russkikh says:
      
      ====================
      net: aquantia: Atlantic driver 10/2017 updates
      
      This patchset fixes various issues in driver,
      improves parameters for better performance on 10Gbit link
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43ebf97f
    • Igor Russkikh's avatar
      net: aquantia: Bad udp rate on default interrupt coalescing · 417a3ae4
      Igor Russkikh authored
      Default Tx rates cause very long ISR delays on Tx.
      0xff is 510us delay, giving only ~ 2000 interrupts per seconds for
      Tx rings cleanup. With these settings udp tx rate was never higher than
      ~800Mbps on a single stream. Changing min delay to 0xF makes it
      way better with ~6Gbps
      
      TCP stream performance is almost unaffected by this change, since LSO
      optimizations play important role.
      
      CPU load is affected insignificantly by this change.
      Signed-off-by: default avatarPavel Belous <pavel.belous@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      417a3ae4
    • Igor Russkikh's avatar
      net: aquantia: Enable coalescing management via ethtool interface · b82ee71a
      Igor Russkikh authored
      Aquantia NIC allows both TX and RX interrupt throttle rate (ITR)
      management, but this was used in a very limited way via predefined
      values. This patch allows to setup ITR default values via module
      command line arguments and via standard ethtool coalescing settings.
      Signed-off-by: default avatarPavel Belous <pavel.belous@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b82ee71a
    • Igor Russkikh's avatar
      net: aquantia: mmio unmap was not performed on driver removal · 6849540a
      Igor Russkikh authored
      That may lead to mmio resource leakage.
      Signed-off-by: default avatarPavel Belous <pavel.belous@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6849540a
    • Igor Russkikh's avatar
      net: aquantia: Limit number of MSIX irqs to the number of cpus · 4c8bb609
      Igor Russkikh authored
      There is no much practical use from having MSIX vectors more that number
      of cpus, thus cap this first with preconfigured limit, then with number
      of cpus online.
      Signed-off-by: default avatarPavel Belous <pavel.belous@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c8bb609
    • Igor Russkikh's avatar
      net: aquantia: Fixed transient link up/down/up notification · 93d87b8f
      Igor Russkikh authored
      When doing ifconfig down/up, driver did not reported carrier_off neither
      in nic_stop nor in nic_start. That caused link to be visible as "up"
      during couple of seconds immediately after "ifconfig up".
      Signed-off-by: default avatarPavel Belous <pavel.belous@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93d87b8f
    • Igor Russkikh's avatar
      net: aquantia: Add queue restarts stats counter · 5d8d84e9
      Igor Russkikh authored
      Queue stat strings are cleaned up, duplicate stat name strings removed,
      queue restarts counter added
      Signed-off-by: default avatarPavel Belous <pavel.belous@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d8d84e9
    • Igor Russkikh's avatar
      net: aquantia: Reset nic statistics on interface up/down · 65e665e6
      Igor Russkikh authored
      Internal statistics system on chip never gets reset until hardware
      reboot. This is quite inconvenient in terms of ethtool statistics usage.
      
      This patch implements incremental statistics update inside of
      service callback.
      
      Upon nic initialization, first request is done to fetch
      initial stat data, current collected stat data gets cleared.
      Internal statistics mailbox readout is improved to save space and
      increase readability
      Signed-off-by: default avatarPavel Belous <pavel.belous@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65e665e6
    • Matteo Croce's avatar
      udp: make some messages more descriptive · 197df02c
      Matteo Croce authored
      In the UDP code there are two leftover error messages with very few meaning.
      Replace them with a more descriptive error message as some users
      reported them as "strange network error".
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      197df02c
    • Stefano Brivio's avatar
      geneve: Fix function matching VNI and tunnel ID on big-endian · 772e97b5
      Stefano Brivio authored
      On big-endian machines, functions converting between tunnel ID
      and VNI use the three LSBs of tunnel ID storage to map VNI.
      
      The comparison function eq_tun_id_and_vni(), on the other hand,
      attempted to map the VNI from the three MSBs. Fix it by using
      the same check implemented on LE, which maps VNI from the three
      LSBs of tunnel ID.
      
      Fixes: 2e0b26e1 ("geneve: Optimize geneve device lookup.")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: default avatarJakub Sitnicki <jkbs@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      772e97b5
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-4.14-20171019' of... · c69d75ae
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-4.14-20171019' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2017-10-19
      
      this is a pull request of 11 patches for the upcoming 4.14 release.
      
      There are 6 patches by ZHU Yi for the flexcan driver, that work around
      the CAN error handling state transition problems found in various
      incarnations of the flexcan IP core.
      
      The patch by Colin Ian King fixes a potential NULL pointer deref in the
      CAN broad cast manager (bcm). One patch by me replaces a direct deref of a RCU
      protected pointer by rcu_access_pointer. My second patch adds missing
      OOM error handling in af_can. A patch by Stefan Mätje for the esd_usb2
      driver fixes the dlc in received RTR frames. And the last patch is by
      Wolfgang Grandegger, it fixes a busy loop in the gs_usb driver in case
      it runs out of TX contexts.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c69d75ae
    • Dexuan Cui's avatar
      hv_sock: add locking in the open/close/release code paths · b4562ca7
      Dexuan Cui authored
      Without the patch, when hvs_open_connection() hasn't completely established
      a connection (e.g. it has changed sk->sk_state to SS_CONNECTED, but hasn't
      inserted the sock into the connected queue), vsock_stream_connect() may see
      the sk_state change and return the connection to the userspace, and next
      when the userspace closes the connection quickly, hvs_release() may not see
      the connection in the connected queue; finally hvs_open_connection()
      inserts the connection into the queue, but we won't be able to purge the
      connection for ever.
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Cathy Avery <cavery@redhat.com>
      Cc: Rolf Neugebauer <rolf.neugebauer@docker.com>
      Cc: Marcelo Cerri <marcelo.cerri@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4562ca7
    • Gavin Shan's avatar
      net/ncsi: Fix length of GVI response packet · 0a90e251
      Gavin Shan authored
      The length of GVI (GetVersionInfo) response packet should be 40 instead
      of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats.
      
       # ethtool --ncsi eth0 swstats
           :
       RESPONSE     OK       TIMEOUT  ERROR
       =======================================
       GVI          0        0        2
      
      With this applied, no error reported on GVI response packets:
      
       # ethtool --ncsi eth0 swstats
           :
       RESPONSE     OK       TIMEOUT  ERROR
       =======================================
       GVI          2        0        0
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarSamuel Mendoza-Jonas <sam@mendozajonas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a90e251
    • Gavin Shan's avatar
      net/ncsi: Enforce failover on link monitor timeout · 52b4c862
      Gavin Shan authored
      The NCSI channel has been configured to provide service if its link
      monitor timer is enabled, regardless of its state (inactive or active).
      So the timeout event on the link monitor indicates the out-of-service
      on that channel, for which a failover is needed.
      
      This sets NCSI_DEV_RESHUFFLE flag to enforce failover on link monitor
      timeout, regardless the channel's original state (inactive or active).
      Also, the link is put into "down" state to give the failing channel
      lowest priority when selecting for the active channel. The state of
      failing channel should be set to active in order for deinitialization
      and failover to be done.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarSamuel Mendoza-Jonas <sam@mendozajonas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52b4c862
    • Gavin Shan's avatar
      net/ncsi: Disable HWA mode when no channels are found · 100ef01f
      Gavin Shan authored
      When there are no NCSI channels probed, HWA (Hardware Arbitration)
      mode is enabled. It's not correct because HWA depends on the fact:
      NCSI channels exist and all of them support HWA mode. This disables
      HWA when no channels are probed.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarSamuel Mendoza-Jonas <sam@mendozajonas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      100ef01f
    • Samuel Mendoza-Jonas's avatar
      net/ncsi: Stop monitor if channel times out or is inactive · 0795fb20
      Samuel Mendoza-Jonas authored
      ncsi_channel_monitor() misses stopping the channel monitor in several
      places that it should, causing a WARN_ON_ONCE() to trigger when the
      monitor is re-started later, eg:
      
      [  459.040000] WARNING: CPU: 0 PID: 1093 at net/ncsi/ncsi-manage.c:269 ncsi_start_channel_monitor+0x7c/0x90
      [  459.040000] CPU: 0 PID: 1093 Comm: kworker/0:3 Not tainted 4.10.17-gaca2fdd #140
      [  459.040000] Hardware name: ASpeed SoC
      [  459.040000] Workqueue: events ncsi_dev_work
      [  459.040000] [<80010094>] (unwind_backtrace) from [<8000d950>] (show_stack+0x20/0x24)
      [  459.040000] [<8000d950>] (show_stack) from [<801dbf70>] (dump_stack+0x20/0x28)
      [  459.040000] [<801dbf70>] (dump_stack) from [<80018d7c>] (__warn+0xe0/0x108)
      [  459.040000] [<80018d7c>] (__warn) from [<80018e70>] (warn_slowpath_null+0x30/0x38)
      [  459.040000] [<80018e70>] (warn_slowpath_null) from [<803f6a08>] (ncsi_start_channel_monitor+0x7c/0x90)
      [  459.040000] [<803f6a08>] (ncsi_start_channel_monitor) from [<803f7664>] (ncsi_configure_channel+0xdc/0x5fc)
      [  459.040000] [<803f7664>] (ncsi_configure_channel) from [<803f8160>] (ncsi_dev_work+0xac/0x474)
      [  459.040000] [<803f8160>] (ncsi_dev_work) from [<8002d244>] (process_one_work+0x1e0/0x450)
      [  459.040000] [<8002d244>] (process_one_work) from [<8002d510>] (worker_thread+0x5c/0x570)
      [  459.040000] [<8002d510>] (worker_thread) from [<80033614>] (kthread+0x124/0x164)
      [  459.040000] [<80033614>] (kthread) from [<8000a5e8>] (ret_from_fork+0x14/0x2c)
      
      This also updates the monitor instead of just returning if
      ncsi_xmit_cmd() fails to send the get-link-status command so that the
      monitor properly times out.
      
      Fixes: e6f44ed6 "net/ncsi: Package and channel management"
      Signed-off-by: default avatarSamuel Mendoza-Jonas <sam@mendozajonas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0795fb20
    • Samuel Mendoza-Jonas's avatar
      net/ncsi: Fix AEN HNCDSC packet length · 6850d0f8
      Samuel Mendoza-Jonas authored
      Correct the value of the HNCDSC AEN packet.
      Fixes: 7a82ecf4 "net/ncsi: NCSI AEN packet handler"
      Signed-off-by: default avatarSamuel Mendoza-Jonas <sam@mendozajonas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6850d0f8
    • Eric Dumazet's avatar
      packet: avoid panic in packet_getsockopt() · 509c7a1e
      Eric Dumazet authored
      syzkaller got crashes in packet_getsockopt() processing
      PACKET_ROLLOVER_STATS command while another thread was managing
      to change po->rollover
      
      Using RCU will fix this bug. We might later add proper RCU annotations
      for sparse sake.
      
      In v2: I replaced kfree(rollover) in fanout_add() to kfree_rcu()
      variant, as spotted by John.
      
      Fixes: a9b63918 ("packet: rollover statistics")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Cc: John Sperbeck <jsperbeck@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      509c7a1e
    • Eric Dumazet's avatar
      tcp/dccp: fix ireq->opt races · c92e8c02
      Eric Dumazet authored
      syzkaller found another bug in DCCP/TCP stacks [1]
      
      For the reasons explained in commit ce105008 ("tcp/dccp: fix
      ireq->pktopts race"), we need to make sure we do not access
      ireq->opt unless we own the request sock.
      
      Note the opt field is renamed to ireq_opt to ease grep games.
      
      [1]
      BUG: KASAN: use-after-free in ip_queue_xmit+0x1687/0x18e0 net/ipv4/ip_output.c:474
      Read of size 1 at addr ffff8801c951039c by task syz-executor5/3295
      
      CPU: 1 PID: 3295 Comm: syz-executor5 Not tainted 4.14.0-rc4+ #80
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:52
       print_address_description+0x73/0x250 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351 [inline]
       kasan_report+0x25b/0x340 mm/kasan/report.c:409
       __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
       ip_queue_xmit+0x1687/0x18e0 net/ipv4/ip_output.c:474
       tcp_transmit_skb+0x1ab7/0x3840 net/ipv4/tcp_output.c:1135
       tcp_send_ack.part.37+0x3bb/0x650 net/ipv4/tcp_output.c:3587
       tcp_send_ack+0x49/0x60 net/ipv4/tcp_output.c:3557
       __tcp_ack_snd_check+0x2c6/0x4b0 net/ipv4/tcp_input.c:5072
       tcp_ack_snd_check net/ipv4/tcp_input.c:5085 [inline]
       tcp_rcv_state_process+0x2eff/0x4850 net/ipv4/tcp_input.c:6071
       tcp_child_process+0x342/0x990 net/ipv4/tcp_minisocks.c:816
       tcp_v4_rcv+0x1827/0x2f80 net/ipv4/tcp_ipv4.c:1682
       ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216
       NF_HOOK include/linux/netfilter.h:249 [inline]
       ip_local_deliver+0x1ce/0x6e0 net/ipv4/ip_input.c:257
       dst_input include/net/dst.h:464 [inline]
       ip_rcv_finish+0x887/0x19a0 net/ipv4/ip_input.c:397
       NF_HOOK include/linux/netfilter.h:249 [inline]
       ip_rcv+0xc3f/0x1820 net/ipv4/ip_input.c:493
       __netif_receive_skb_core+0x1a3e/0x34b0 net/core/dev.c:4476
       __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4514
       netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4587
       netif_receive_skb+0xae/0x390 net/core/dev.c:4611
       tun_rx_batched.isra.50+0x5ed/0x860 drivers/net/tun.c:1372
       tun_get_user+0x249c/0x36d0 drivers/net/tun.c:1766
       tun_chr_write_iter+0xbf/0x160 drivers/net/tun.c:1792
       call_write_iter include/linux/fs.h:1770 [inline]
       new_sync_write fs/read_write.c:468 [inline]
       __vfs_write+0x68a/0x970 fs/read_write.c:481
       vfs_write+0x18f/0x510 fs/read_write.c:543
       SYSC_write fs/read_write.c:588 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:580
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x40c341
      RSP: 002b:00007f469523ec10 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 000000000040c341
      RDX: 0000000000000037 RSI: 0000000020004000 RDI: 0000000000000015
      RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
      R10: 00000000000f4240 R11: 0000000000000293 R12: 00000000004b7fd1
      R13: 00000000ffffffff R14: 0000000020000000 R15: 0000000000025000
      
      Allocated by task 3295:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
       __do_kmalloc mm/slab.c:3725 [inline]
       __kmalloc+0x162/0x760 mm/slab.c:3734
       kmalloc include/linux/slab.h:498 [inline]
       tcp_v4_save_options include/net/tcp.h:1962 [inline]
       tcp_v4_init_req+0x2d3/0x3e0 net/ipv4/tcp_ipv4.c:1271
       tcp_conn_request+0xf6d/0x3410 net/ipv4/tcp_input.c:6283
       tcp_v4_conn_request+0x157/0x210 net/ipv4/tcp_ipv4.c:1313
       tcp_rcv_state_process+0x8ea/0x4850 net/ipv4/tcp_input.c:5857
       tcp_v4_do_rcv+0x55c/0x7d0 net/ipv4/tcp_ipv4.c:1482
       tcp_v4_rcv+0x2d10/0x2f80 net/ipv4/tcp_ipv4.c:1711
       ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216
       NF_HOOK include/linux/netfilter.h:249 [inline]
       ip_local_deliver+0x1ce/0x6e0 net/ipv4/ip_input.c:257
       dst_input include/net/dst.h:464 [inline]
       ip_rcv_finish+0x887/0x19a0 net/ipv4/ip_input.c:397
       NF_HOOK include/linux/netfilter.h:249 [inline]
       ip_rcv+0xc3f/0x1820 net/ipv4/ip_input.c:493
       __netif_receive_skb_core+0x1a3e/0x34b0 net/core/dev.c:4476
       __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4514
       netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4587
       netif_receive_skb+0xae/0x390 net/core/dev.c:4611
       tun_rx_batched.isra.50+0x5ed/0x860 drivers/net/tun.c:1372
       tun_get_user+0x249c/0x36d0 drivers/net/tun.c:1766
       tun_chr_write_iter+0xbf/0x160 drivers/net/tun.c:1792
       call_write_iter include/linux/fs.h:1770 [inline]
       new_sync_write fs/read_write.c:468 [inline]
       __vfs_write+0x68a/0x970 fs/read_write.c:481
       vfs_write+0x18f/0x510 fs/read_write.c:543
       SYSC_write fs/read_write.c:588 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:580
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      Freed by task 3306:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
       __cache_free mm/slab.c:3503 [inline]
       kfree+0xca/0x250 mm/slab.c:3820
       inet_sock_destruct+0x59d/0x950 net/ipv4/af_inet.c:157
       __sk_destruct+0xfd/0x910 net/core/sock.c:1560
       sk_destruct+0x47/0x80 net/core/sock.c:1595
       __sk_free+0x57/0x230 net/core/sock.c:1603
       sk_free+0x2a/0x40 net/core/sock.c:1614
       sock_put include/net/sock.h:1652 [inline]
       inet_csk_complete_hashdance+0xd5/0xf0 net/ipv4/inet_connection_sock.c:959
       tcp_check_req+0xf4d/0x1620 net/ipv4/tcp_minisocks.c:765
       tcp_v4_rcv+0x17f6/0x2f80 net/ipv4/tcp_ipv4.c:1675
       ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216
       NF_HOOK include/linux/netfilter.h:249 [inline]
       ip_local_deliver+0x1ce/0x6e0 net/ipv4/ip_input.c:257
       dst_input include/net/dst.h:464 [inline]
       ip_rcv_finish+0x887/0x19a0 net/ipv4/ip_input.c:397
       NF_HOOK include/linux/netfilter.h:249 [inline]
       ip_rcv+0xc3f/0x1820 net/ipv4/ip_input.c:493
       __netif_receive_skb_core+0x1a3e/0x34b0 net/core/dev.c:4476
       __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4514
       netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4587
       netif_receive_skb+0xae/0x390 net/core/dev.c:4611
       tun_rx_batched.isra.50+0x5ed/0x860 drivers/net/tun.c:1372
       tun_get_user+0x249c/0x36d0 drivers/net/tun.c:1766
       tun_chr_write_iter+0xbf/0x160 drivers/net/tun.c:1792
       call_write_iter include/linux/fs.h:1770 [inline]
       new_sync_write fs/read_write.c:468 [inline]
       __vfs_write+0x68a/0x970 fs/read_write.c:481
       vfs_write+0x18f/0x510 fs/read_write.c:543
       SYSC_write fs/read_write.c:588 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:580
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      Fixes: e994b2f0 ("tcp: do not lock listener to process SYN packets")
      Fixes: 079096f1 ("tcp/dccp: install syn_recv requests into ehash table")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c92e8c02
  3. 20 Oct, 2017 7 commits
  4. 19 Oct, 2017 8 commits
    • Xin Long's avatar
      sctp: do not peel off an assoc from one netns to another one · df80cd9b
      Xin Long authored
      Now when peeling off an association to the sock in another netns, all
      transports in this assoc are not to be rehashed and keep use the old
      key in hashtable.
      
      As a transport uses sk->net as the hash key to insert into hashtable,
      it would miss removing these transports from hashtable due to the new
      netns when closing the sock and all transports are being freeed, then
      later an use-after-free issue could be caused when looking up an asoc
      and dereferencing those transports.
      
      This is a very old issue since very beginning, ChunYu found it with
      syzkaller fuzz testing with this series:
      
        socket$inet6_sctp()
        bind$inet6()
        sendto$inet6()
        unshare(0x40000000)
        getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
        getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
      
      This patch is to block this call when peeling one assoc off from one
      netns to another one, so that the netns of all transport would not
      go out-sync with the key in hashtable.
      
      Note that this patch didn't fix it by rehashing transports, as it's
      difficult to handle the situation when the tuple is already in use
      in the new netns. Besides, no one would like to peel off one assoc
      to another netns, considering ipaddrs, ifaces, etc. are usually
      different.
      Reported-by: default avatarChunYu Wang <chunwang@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df80cd9b
    • David S. Miller's avatar
      Merge branch 'bpf-Fix-for-BPF-devmap-percpu-allocation-splat' · 4bbb5083
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      bpf: Fix for BPF devmap percpu allocation splat
      
      The set fixes a splat in devmap percpu allocation when we alloc
      the flush bitmap. Patch 1 is a prerequisite for the fix in patch 2,
      patch 1 is rather small, so if this could be routed via -net, for
      example, with Tejun's Ack that would be good. Patch 3 gets rid of
      remaining PCPU_MIN_UNIT_SIZE checks, which are percpu allocator
      internals and should not be used.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bbb5083
    • Daniel Borkmann's avatar
      bpf: do not test for PCPU_MIN_UNIT_SIZE before percpu allocations · bc6d5031
      Daniel Borkmann authored
      PCPU_MIN_UNIT_SIZE is an implementation detail of the percpu
      allocator. Given we support __GFP_NOWARN now, lets just let
      the allocation request fail naturally instead. The two call
      sites from BPF mistakenly assumed __GFP_NOWARN would work, so
      no changes needed to their actual __alloc_percpu_gfp() calls
      which use the flag already.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc6d5031
    • Daniel Borkmann's avatar
      bpf: fix splat for illegal devmap percpu allocation · 82f8dd28
      Daniel Borkmann authored
      It was reported that syzkaller was able to trigger a splat on
      devmap percpu allocation due to illegal/unsupported allocation
      request size passed to __alloc_percpu():
      
        [   70.094249] illegal size (32776) or align (8) for percpu allocation
        [   70.094256] ------------[ cut here ]------------
        [   70.094259] WARNING: CPU: 3 PID: 3451 at mm/percpu.c:1365 pcpu_alloc+0x96/0x630
        [...]
        [   70.094325] Call Trace:
        [   70.094328]  __alloc_percpu_gfp+0x12/0x20
        [   70.094330]  dev_map_alloc+0x134/0x1e0
        [   70.094331]  SyS_bpf+0x9bc/0x1610
        [   70.094333]  ? selinux_task_setrlimit+0x5a/0x60
        [   70.094334]  ? security_task_setrlimit+0x43/0x60
        [   70.094336]  entry_SYSCALL_64_fastpath+0x1a/0xa5
      
      This was due to too large max_entries for the map such that we
      surpassed the upper limit of PCPU_MIN_UNIT_SIZE. It's fine to
      fail naturally here, so switch to __alloc_percpu_gfp() and pass
      __GFP_NOWARN instead.
      
      Fixes: 11393cc9 ("xdp: Add batching support to redirect map")
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarShankara Pailoor <sp3485@columbia.edu>
      Reported-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82f8dd28
    • Daniel Borkmann's avatar
      mm, percpu: add support for __GFP_NOWARN flag · 0ea7eeec
      Daniel Borkmann authored
      Add an option for pcpu_alloc() to support __GFP_NOWARN flag.
      Currently, we always throw a warning when size or alignment
      is unsupported (and also dump stack on failed allocation
      requests). The warning itself is harmless since we return
      NULL anyway for any failed request, which callers are
      required to handle anyway. However, it becomes harmful when
      panic_on_warn is set.
      
      The rationale for the WARN() in pcpu_alloc() is that it can
      be tracked when larger than supported allocation requests are
      made such that allocations limits can be tweaked if warranted.
      This makes sense for in-kernel users, however, there are users
      of pcpu allocator where allocation size is derived from user
      space requests, e.g. when creating BPF maps. In these cases,
      the requests should fail gracefully without throwing a splat.
      
      The current work-around was to check allocation size against
      the upper limit of PCPU_MIN_UNIT_SIZE from call-sites for
      bailing out prior to a call to pcpu_alloc() in order to
      avoid throwing the WARN(). This is bad in multiple ways since
      PCPU_MIN_UNIT_SIZE is an implementation detail, and having
      the checks on call-sites only complicates the code for no
      good reason. Thus, lets fix it generically by supporting the
      __GFP_NOWARN flag that users can then use with calling the
      __alloc_percpu_gfp() helper instead.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ea7eeec
    • David S. Miller's avatar
      Merge branch 'ena-fixes' · 3fd3b03b
      David S. Miller authored
      Netanel Belgazal says:
      
      ====================
      ENA ethernet driver bug fixes
      
      Some fixes for ENA ethernet driver
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3fd3b03b
    • Netanel Belgazal's avatar
      net: ena: fix wrong max Tx/Rx queues on ethtool · a59df396
      Netanel Belgazal authored
      ethtool ena_get_channels() expose the max number of queues as the max
      number of queues ENA supports (128 queues) and not the actual number
      of created queues.
      Signed-off-by: default avatarNetanel Belgazal <netanel@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a59df396
    • Netanel Belgazal's avatar
      net: ena: fix rare kernel crash when bar memory remap fails · 411838e7
      Netanel Belgazal authored
      This failure is rare and only found on testing where deliberately fail
      devm_ioremap()
      
      [  451.170464] ena 0000:04:00.0: failed to remap regs bar
      451.170549] Workqueue: pciehp-1 pciehp_power_thread
      [  451.170551] task: ffff88085a5f2d00 task.stack: ffffc9000756c000
      [  451.170552] RIP: 0010:devm_iounmap+0x2d/0x40
      [  451.170553] RSP: 0018:ffffc9000756fac0 EFLAGS: 00010282
      [  451.170554] RAX: 00000000fffffffe RBX: 0000000000000000 RCX:
      0000000000000000
      [  451.170555] RDX: ffffffff813a7e00 RSI: 0000000000000282 RDI:
      0000000000000282
      [  451.170556] RBP: ffffc9000756fac8 R08: 00000000fffffffe R09:
      00000000000009b7
      [  451.170557] R10: 0000000000000005 R11: 00000000000009b6 R12:
      ffff880856c9d0a0
      [  451.170558] R13: ffffc9000f5c90c0 R14: ffff880856c9d0a0 R15:
      0000000000000028
      [  451.170559] FS:  0000000000000000(0000) GS:ffff88085f400000(0000)
      knlGS:0000000000000000
      [  451.170560] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  451.170561] CR2: 00007f169038b000 CR3: 0000000001c09000 CR4:
      00000000003406f0
      [  451.170562] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [  451.170562] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
      0000000000000400
      [  451.170563] Call Trace:
      [  451.170572]  ena_release_bars.isra.48+0x34/0x60 [ena]
      [  451.170574]  ena_probe+0x144/0xd90 [ena]
      [  451.170579]  ? ida_simple_get+0x98/0x100
      [  451.170585]  ? kernfs_next_descendant_post+0x40/0x50
      [  451.170591]  local_pci_probe+0x45/0xa0
      [  451.170592]  pci_device_probe+0x157/0x180
      [  451.170599]  driver_probe_device+0x2a8/0x460
      [  451.170600]  __device_attach_driver+0x7e/0xe0
      [  451.170602]  ? driver_allows_async_probing+0x30/0x30
      [  451.170603]  bus_for_each_drv+0x68/0xb0
      [  451.170605]  __device_attach+0xdd/0x160
      [  451.170607]  device_attach+0x10/0x20
      [  451.170610]  pci_bus_add_device+0x4f/0xa0
      [  451.170611]  pci_bus_add_devices+0x39/0x70
      [  451.170613]  pciehp_configure_device+0x96/0x120
      [  451.170614]  pciehp_enable_slot+0x1b3/0x290
      [  451.170616]  pciehp_power_thread+0x3b/0xb0
      [  451.170622]  process_one_work+0x149/0x360
      [  451.170623]  worker_thread+0x4d/0x3c0
      [  451.170626]  kthread+0x109/0x140
      [  451.170627]  ? rescuer_thread+0x380/0x380
      [  451.170628]  ? kthread_park+0x60/0x60
      [  451.170632]  ret_from_fork+0x25/0x30
      Signed-off-by: default avatarNetanel Belgazal <netanel@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      411838e7