1. 30 May, 2019 19 commits
    • Willem de Bruijn's avatar
      net: correct zerocopy refcnt with udp MSG_MORE · 100f6d8e
      Willem de Bruijn authored
      TCP zerocopy takes a uarg reference for every skb, plus one for the
      tcp_sendmsg_locked datapath temporarily, to avoid reaching refcnt zero
      as it builds, sends and frees skbs inside its inner loop.
      
      UDP and RAW zerocopy do not send inside the inner loop so do not need
      the extra sock_zerocopy_get + sock_zerocopy_put pair. Commit
      52900d22288ed ("udp: elide zerocopy operation in hot path") introduced
      extra_uref to pass the initial reference taken in sock_zerocopy_alloc
      to the first generated skb.
      
      But, sock_zerocopy_realloc takes this extra reference at the start of
      every call. With MSG_MORE, no new skb may be generated to attach the
      extra_uref to, so refcnt is incorrectly 2 with only one skb.
      
      Do not take the extra ref if uarg && !tcp, which implies MSG_MORE.
      Update extra_uref accordingly.
      
      This conditional assignment triggers a false positive may be used
      uninitialized warning, so have to initialize extra_uref at define.
      
      Changes v1->v2: fix typo in Fixes SHA1
      
      Fixes: 52900d22 ("udp: elide zerocopy operation in hot path")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Diagnosed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      100f6d8e
    • Maxime Chevallier's avatar
      ethtool: Check for vlan etype or vlan tci when parsing flow_rule · b73484b2
      Maxime Chevallier authored
      When parsing an ethtool flow spec to build a flow_rule, the code checks
      if both the vlan etype and the vlan tci are specified by the user to add
      a FLOW_DISSECTOR_KEY_VLAN match.
      
      However, when the user only specified a vlan etype or a vlan tci, this
      check silently ignores these parameters.
      
      For example, the following rule :
      
      ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0
      
      will result in no error being issued, but the equivalent rule will be
      created and passed to the NIC driver :
      
      ethtool -N eth0 flow-type udp4 action -1 loc 0
      
      In the end, neither the NIC driver using the rule nor the end user have
      a way to know that these keys were dropped along the way, or that
      incorrect parameters were entered.
      
      This kind of check should be left to either the driver, or the ethtool
      flow spec layer.
      
      This commit makes so that ethtool parameters are forwarded as-is to the
      NIC driver.
      
      Since none of the users of ethtool_rx_flow_rule_create are using the
      VLAN dissector, I don't think this qualifies as a regression.
      
      Fixes: eca4205f ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator")
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Acked-by: default avatarPablo Neira Ayuso <pablo@gnumonks.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b73484b2
    • Jakub Kicinski's avatar
      net: don't clear sock->sk early to avoid trouble in strparser · 2b81f816
      Jakub Kicinski authored
      af_inet sets sock->sk to NULL which trips strparser over:
      
      BUG: kernel NULL pointer dereference, address: 0000000000000012
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.2.0-rc1-00139-g14629453a6d3 #21
      RIP: 0010:tcp_peek_len+0x10/0x60
      RSP: 0018:ffffc02e41c54b98 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff9cf924c4e030 RCX: 0000000000000051
      RDX: 0000000000000000 RSI: 000000000000000c RDI: ffff9cf97128f480
      RBP: ffff9cf9365e0300 R08: ffff9cf94fe7d2c0 R09: 0000000000000000
      R10: 000000000000036b R11: ffff9cf939735e00 R12: ffff9cf91ad9ae40
      R13: ffff9cf924c4e000 R14: ffff9cf9a8fcbaae R15: 0000000000000020
      FS: 0000000000000000(0000) GS:ffff9cf9af7c0000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000012 CR3: 000000013920a003 CR4: 00000000003606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
       <IRQ>
       strp_data_ready+0x48/0x90
       tls_data_ready+0x22/0xd0 [tls]
       tcp_rcv_established+0x569/0x620
       tcp_v4_do_rcv+0x127/0x1e0
       tcp_v4_rcv+0xad7/0xbf0
       ip_protocol_deliver_rcu+0x2c/0x1c0
       ip_local_deliver_finish+0x41/0x50
       ip_local_deliver+0x6b/0xe0
       ? ip_protocol_deliver_rcu+0x1c0/0x1c0
       ip_rcv+0x52/0xd0
       ? ip_rcv_finish_core.isra.20+0x380/0x380
       __netif_receive_skb_one_core+0x7e/0x90
       netif_receive_skb_internal+0x42/0xf0
       napi_gro_receive+0xed/0x150
       nfp_net_poll+0x7a2/0xd30 [nfp]
       ? kmem_cache_free_bulk+0x286/0x310
       net_rx_action+0x149/0x3b0
       __do_softirq+0xe3/0x30a
       ? handle_irq_event_percpu+0x6a/0x80
       irq_exit+0xe8/0xf0
       do_IRQ+0x85/0xd0
       common_interrupt+0xf/0xf
       </IRQ>
      RIP: 0010:cpuidle_enter_state+0xbc/0x450
      
      To avoid this issue set sock->sk after sk_prot->close.
      My grepping and testing did not discover any code which
      would depend on the current behaviour.
      
      Fixes: c46234eb ("tls: RX path for ktls")
      Reported-by: default avatarDavid Beckett <david.beckett@netronome.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b81f816
    • Eric Dumazet's avatar
      net-gro: fix use-after-free read in napi_gro_frags() · a4270d67
      Eric Dumazet authored
      If a network driver provides to napi_gro_frags() an
      skb with a page fragment of exactly 14 bytes, the call
      to gro_pull_from_frag0() will 'consume' the fragment
      by calling skb_frag_unref(skb, 0), and the page might
      be freed and reused.
      
      Reading eth->h_proto at the end of napi_frags_skb() might
      read mangled data, or crash under specific debugging features.
      
      BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline]
      BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
      Read of size 2 at addr ffff88809366840c by task syz-executor599/8957
      
      CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
       napi_frags_skb net/core/dev.c:5833 [inline]
       napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
       tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037
       call_write_iter include/linux/fs.h:1872 [inline]
       do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
       do_iter_write fs/read_write.c:970 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:951
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
       do_writev+0x15b/0x330 fs/read_write.c:1058
      
      Fixes: a50e233c ("net-gro: restore frag0 optimization")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4270d67
    • David S. Miller's avatar
      Merge branch 'Fixes-for-DSA-tagging-using-802-1Q' · c3bc6deb
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Fixes for DSA tagging using 802.1Q
      
      During the prototyping for the "Decoupling PHYLINK from struct
      net_device" patchset, the CPU port of the sja1105 driver was moved to a
      different spot.  This uncovered an issue in the tag_8021q DSA code,
      which used to work by mistake - the CPU port was the last hardware port
      numerically, and this was masking an ordering issue which is very likely
      to be seen in other drivers that make use of 802.1Q tags.
      
      A question was also raised whether the VID numbers bear any meaning, and
      the conclusion was that they don't, at least not in an absolute sense.
      The second patch defines bit fields inside the DSA 802.1Q VID so that
      tcpdump can decode it unambiguously (although the meaning is now clear
      even by visual inspection).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3bc6deb
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: Create a stable binary format · 0471dd42
      Vladimir Oltean authored
      Tools like tcpdump need to be able to decode the significance of fake
      VLAN headers that DSA uses to separate switch ports.
      
      But currently these have no global significance - they are simply an
      ordered list of DSA_MAX_SWITCHES x DSA_MAX_PORTS numbers ending at 4095.
      
      The reason why this is submitted as a fix is that the existing mapping
      of VIDs should not enter into a stable kernel, so we can pretend that
      only the new format exists. This way tcpdump won't need to try to make
      something out of the VLAN tags on 5.2 kernels.
      
      Fixes: f9bbe447 ("net: dsa: Optional VLAN-based port separation for switches without tagging")
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0471dd42
    • Ioana Ciornei's avatar
      net: dsa: tag_8021q: Change order of rx_vid setup · d34d2baa
      Ioana Ciornei authored
      The 802.1Q tagging performs an unbalanced setup in terms of RX VIDs on
      the CPU port. For the ingress path of a 802.1Q switch to work, the RX
      VID of a port needs to be seen as tagged egress on the CPU port.
      
      While configuring the other front-panel ports to be part of this VID,
      for bridge scenarios, the untagged flag is applied even on the CPU port
      in dsa_switch_vlan_add.  This happens because DSA applies the same flags
      on the CPU port as on the (bridge-controlled) slave ports, and the
      effect in this case is that the CPU port tagged settings get deleted.
      
      Instead of fixing DSA by introducing a way to control VLAN flags on the
      CPU port (and hence stop inheriting from the slave ports) - a hard,
      perhaps intractable problem - avoid this situation by moving the setup
      part of the RX VID on the CPU port after all the other front-panel ports
      have been added to the VID.
      
      Fixes: f9bbe447 ("net: dsa: Optional VLAN-based port separation for switches without tagging")
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d34d2baa
    • Antoine Tenart's avatar
      net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value · 21808437
      Antoine Tenart authored
      MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but
      the current code is passing the global tx queue offset, so it ends
      up writing to unknown registers (between 0x8280 and 0x82fc, which
      seemed to be unused by the hardware). This fixes the issue by using
      the logical queue id instead.
      
      Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit")
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21808437
    • Young Xiao's avatar
      ipv4: tcp_input: fix stack out of bounds when parsing TCP options. · 9609dad2
      Young Xiao authored
      The TCP option parsing routines in tcp_parse_options function could
      read one byte out of the buffer of the TCP options.
      
      1         while (length > 0) {
      2                 int opcode = *ptr++;
      3                 int opsize;
      4
      5                 switch (opcode) {
      6                 case TCPOPT_EOL:
      7                         return;
      8                 case TCPOPT_NOP:        /* Ref: RFC 793 section 3.1 */
      9                         length--;
      10                        continue;
      11                default:
      12                        opsize = *ptr++; //out of bound access
      
      If length = 1, then there is an access in line2.
      And another access is occurred in line 12.
      This would lead to out-of-bound access.
      
      Therefore, in the patch we check that the available data length is
      larger enough to pase both TCP option code and size.
      Signed-off-by: default avatarYoung Xiao <92siuyang@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9609dad2
    • David S. Miller's avatar
      Merge branch 'mlxsw-Two-small-fixes' · 62851d71
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Two small fixes
      
      Patch #1 from Jiri fixes an issue specific to Spectrum-2 where the
      insertion of two identical flower filters with different priorities
      would trigger a warning.
      
      Patch #2 from Amit prevents the driver from trying to configure a port
      with a speed of 56Gb/s and autoneg off as this is not supported and
      results in error messages from firmware.
      
      Please consider patch #1 for stable.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62851d71
    • Amit Cohen's avatar
      mlxsw: spectrum: Prevent force of 56G · 275e928f
      Amit Cohen authored
      Force of 56G is not supported by hardware in Ethernet devices. This
      configuration fails with a bad parameter error from firmware.
      
      Add check of this case. Instead of trying to set 56G with autoneg off,
      return a meaningful error.
      
      Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
      Signed-off-by: default avatarAmit Cohen <amitc@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      275e928f
    • Jiri Pirko's avatar
      mlxsw: spectrum_acl: Avoid warning after identical rules insertion · ef744220
      Jiri Pirko authored
      When identical rules are inserted, the latter one goes to C-TCAM. For
      that, a second eRP with the same mask is created. These 2 eRPs by the
      nature cannot be merged and also one cannot be parent of another.
      Teach mlxsw_sp_acl_erp_delta_fill() about this possibility and handle it
      gracefully.
      Reported-by: default avatarAlex Kushnarov <alexanderk@mellanox.com>
      Fixes: c22291f7 ("mlxsw: spectrum: acl: Implement delta for ERP")
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef744220
    • Rasmus Villemoes's avatar
      net: dsa: mv88e6xxx: fix handling of upper half of STATS_TYPE_PORT · 84b3fd1f
      Rasmus Villemoes authored
      Currently, the upper half of a 4-byte STATS_TYPE_PORT statistic ends
      up in bits 47:32 of the return value, instead of bits 31:16 as they
      should.
      
      Fixes: 6e46e2d8 ("net: dsa: mv88e6xxx: Fix u64 statistics")
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84b3fd1f
    • Heiner Kallweit's avatar
      r8169: fix MAC address being lost in PCI D3 · 59715171
      Heiner Kallweit authored
      (At least) RTL8168e forgets its MAC address in PCI D3. To fix this set
      the MAC address when resuming. For resuming from runtime-suspend we
      had this in place already, for resuming from S3/S5 it was missing.
      
      The commit referenced as being fixed isn't wrong, it's just the first
      one where the patch applies cleanly.
      
      Fixes: 0f07bd85 ("r8169: use dev_get_drvdata where possible")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reported-by: default avatarAlbert Astals Cid <aacid@kde.org>
      Tested-by: default avatarAlbert Astals Cid <aacid@kde.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59715171
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2019-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 200c6758
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      Mellanox, mlx5 fixes 2019-05-28
      
      This series introduces some fixes to mlx5 driver.
      
      Please pull and let me know if there is any problem.
      
      For -stable v4.13:
      ('net/mlx5: Allocate root ns memory using kzalloc to match kfree')
      
      For -stable v4.16:
      ('net/mlx5: Avoid double free in fs init error unwinding path')
      
      For -stable v4.18:
      ('net/mlx5e: Disable rxhash when CQE compress is enabled')
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      200c6758
    • David S. Miller's avatar
      Merge branch 'XDP-generic-fixes' · 4b280531
      David S. Miller authored
      Stephen Hemminger says:
      
      ====================
      XDP generic fixes
      
      This set of patches came about while investigating XDP
      generic on Azure. The split brain nature of the accelerated
      networking exposed issues with the stack device model.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b280531
    • Stephen Hemminger's avatar
      net: core: support XDP generic on stacked devices. · 458bf2f2
      Stephen Hemminger authored
      When a device is stacked like (team, bonding, failsafe or netvsc) the
      XDP generic program for the parent device was not called.
      
      Move the call to XDP generic inside __netif_receive_skb_core where
      it can be done multiple times for stacked case.
      
      Fixes: d4455169 ("net: xdp: support xdp generic on virtual devices")
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      458bf2f2
    • Stephen Hemminger's avatar
      netvsc: unshare skb in VF rx handler · 996ed047
      Stephen Hemminger authored
      The netvsc VF skb handler should make sure that skb is not
      shared. Similar logic already exists in bonding and team device
      drivers.
      
      This is not an issue in practice because the VF devicex
      does not send up shared skb's. But the netvsc driver
      should do the right thing if it did.
      
      Fixes: 0c195567 ("netvsc: transparent VF management")
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      996ed047
    • Sean Tranchetti's avatar
      udp: Avoid post-GRO UDP checksum recalculation · f2696099
      Sean Tranchetti authored
      Currently, when resegmenting an unexpected UDP GRO packet, the full UDP
      checksum will be calculated for every new SKB created by skb_segment()
      because the netdev features passed in by udp_rcv_segment() lack any
      information about checksum offload capabilities.
      
      Usually, we have no need to perform this calculation again, as
        1) The GRO implementation guarantees that any packets making it to the
           udp_rcv_segment() function had correct checksums, and, more
           importantly,
        2) Upon the successful return of udp_rcv_segment(), we immediately pull
           the UDP header off and either queue the segment to the socket or
           hand it off to a new protocol handler.
      
      Unless userspace has set the IP_CHECKSUM sockopt to indicate that they
      want the final checksum values, we can pass the needed netdev feature
      flags to __skb_gso_segment() to avoid checksumming each segment in
      skb_segment().
      
      Fixes: cf329aa4 ("udp: cope with UDP GRO packet misdirection")
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: default avatarSean Tranchetti <stranche@codeaurora.org>
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2696099
  2. 29 May, 2019 17 commits
  3. 28 May, 2019 3 commits
  4. 27 May, 2019 1 commit