1. 06 Apr, 2021 3 commits
    • Xin Long's avatar
      tipc: increment the tmp aead refcnt before attaching it · 2a2403ca
      Xin Long authored
      Li Shuang found a NULL pointer dereference crash in her testing:
      
        [] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
        [] RIP: 0010:tipc_crypto_rcv_complete+0xc8/0x7e0 [tipc]
        [] Call Trace:
        []  <IRQ>
        []  tipc_crypto_rcv+0x2d9/0x8f0 [tipc]
        []  tipc_rcv+0x2fc/0x1120 [tipc]
        []  tipc_udp_recv+0xc6/0x1e0 [tipc]
        []  udpv6_queue_rcv_one_skb+0x16a/0x460
        []  udp6_unicast_rcv_skb.isra.35+0x41/0xa0
        []  ip6_protocol_deliver_rcu+0x23b/0x4c0
        []  ip6_input+0x3d/0xb0
        []  ipv6_rcv+0x395/0x510
        []  __netif_receive_skb_core+0x5fc/0xc40
      
      This is caused by NULL returned by tipc_aead_get(), and then crashed when
      dereferencing it later in tipc_crypto_rcv_complete(). This might happen
      when tipc_crypto_rcv_complete() is called by two threads at the same time:
      the tmp attached by tipc_crypto_key_attach() in one thread may be released
      by the one attached by that in the other thread.
      
      This patch is to fix it by incrementing the tmp's refcnt before attaching
      it instead of calling tipc_aead_get() after attaching it.
      
      Fixes: fc1b6d6d ("tipc: introduce TIPC encryption & authentication")
      Reported-by: default avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a2403ca
    • Eric Dumazet's avatar
      virtio_net: Do not pull payload in skb->head · 0f6925b3
      Eric Dumazet authored
      Xuan Zhuo reported that commit 3226b158 ("net: avoid 32 x truesize
      under-estimation for tiny skbs") brought  a ~10% performance drop.
      
      The reason for the performance drop was that GRO was forced
      to chain sk_buff (using skb_shinfo(skb)->frag_list), which
      uses more memory but also cause packet consumers to go over
      a lot of overhead handling all the tiny skbs.
      
      It turns out that virtio_net page_to_skb() has a wrong strategy :
      It allocates skbs with GOOD_COPY_LEN (128) bytes in skb->head, then
      copies 128 bytes from the page, before feeding the packet to GRO stack.
      
      This was suboptimal before commit 3226b158 ("net: avoid 32 x truesize
      under-estimation for tiny skbs") because GRO was using 2 frags per MSS,
      meaning we were not packing MSS with 100% efficiency.
      
      Fix is to pull only the ethernet header in page_to_skb()
      
      Then, we change virtio_net_hdr_to_skb() to pull the missing
      headers, instead of assuming they were already pulled by callers.
      
      This fixes the performance regression, but could also allow virtio_net
      to accept packets with more than 128bytes of headers.
      
      Many thanks to Xuan Zhuo for his report, and his tests/help.
      
      Fixes: 3226b158 ("net: avoid 32 x truesize under-estimation for tiny skbs")
      Reported-by: default avatarXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Link: https://www.spinics.net/lists/netdev/msg731397.htmlCo-Developed-by: default avatarXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Signed-off-by: default avatarXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: virtualization@lists.linux-foundation.org
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f6925b3
    • Lv Yunlong's avatar
      net: broadcom: bcm4908enet: Fix a double free in bcm4908_enet_dma_alloc · b25b343d
      Lv Yunlong authored
      In bcm4908_enet_dma_alloc, if callee bcm4908_dma_alloc_buf_descs() failed,
      it will free the ring->cpu_addr by dma_free_coherent() and return error.
      Then bcm4908_enet_dma_free() will be called, and free the same cpu_addr
      by dma_free_coherent() again.
      
      My patch set ring->cpu_addr to NULL after it is freed in
      bcm4908_dma_alloc_buf_descs() to avoid the double free.
      
      Fixes: 4feffead ("net: broadcom: bcm4908enet: add BCM4908 controller driver")
      Signed-off-by: default avatarLv Yunlong <lyl2019@mail.ustc.edu.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b25b343d
  2. 05 Apr, 2021 6 commits
  3. 02 Apr, 2021 3 commits
  4. 01 Apr, 2021 17 commits
  5. 31 Mar, 2021 11 commits
    • Ong Boon Leong's avatar
      xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model · 622d1369
      Ong Boon Leong authored
      xdp_return_frame() may be called outside of NAPI context to return
      xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
      napi_direct = false. For page_pool memory model, __xdp_return() calls
      xdp_return_frame_no_direct() unconditionally and below false negative
      kernel BUG throw happened under preempt-rt build:
      
      [  430.450355] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/3884
      [  430.451678] caller is __xdp_return+0x1ff/0x2e0
      [  430.452111] CPU: 0 PID: 3884 Comm: modprobe Tainted: G     U      E     5.12.0-rc2+ #45
      
      Changes in v2:
       - This patch fixes the issue by making xdp_return_frame_no_direct() is
         only called if napi_direct = true, as recommended for better by
         Jesper Dangaard Brouer. Thanks!
      
      Fixes: 2539650f ("xdp: Helpers for disabling napi_direct of xdp_return_frame")
      Signed-off-by: default avatarOng Boon Leong <boon.leong.ong@intel.com>
      Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      622d1369
    • Eric Dumazet's avatar
      Revert "net: correct sk_acceptq_is_full()" · c609e6aa
      Eric Dumazet authored
      This reverts commit f211ac15.
      
      We had similar attempt in the past, and we reverted it.
      
      History:
      
      64a14651 [NET]: Revert incorrect accept queue backlog changes.
      8488df89 [NET]: Fix bugs in "Whether sock accept queue is full" checking
      
      I am adding a fat comment so that future attempts will
      be much harder.
      
      Fixes: f211ac15 ("net: correct sk_acceptq_is_full()")
      Cc: iuyacan <yacanliu@163.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c609e6aa
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2021-03-31' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 9dc22c0d
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5 fixes 2021-03-31
      
      This series introduces some fixes to mlx5 driver.
      Please pull and let me know if there is any problem.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9dc22c0d
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · c9170f13
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2021-03-31
      
      1) Fix ipv4 pmtu checks for xfrm anf vti interfaces.
         From Eyal Birger.
      
      2) There are situations where the socket passed to
         xfrm_output_resume() is not the same as the one
         attached to the skb. Use the socket passed to
         xfrm_output_resume() to avoid lookup failures
         when xfrm is used with VRFs.
         From Evan Nimmo.
      
      3) Make the xfrm_state_hash_generation sequence counter per
         network namespace because but its write serialization
         lock is also per network namespace. Write protection
         is insufficient otherwise.
         From Ahmed S. Darwish.
      
      4) Fixup sctp featue flags when used with esp offload.
         From Xin Long.
      
      5) xfrm BEET mode doesn't support fragments for inner packets.
         This is a limitation of the protocol, so no fix possible.
         Warn at least to notify the user about that situation.
         From Xin Long.
      
      6) Fix NULL pointer dereference on policy lookup when
         namespaces are uses in combination with esp offload.
      
      7) Fix incorrect transformation on esp offload when
         packets get segmented at layer 3.
      
      8) Fix some user triggered usages of WARN_ONCE in
         the xfrm compat layer.
         From Dmitry Safonov.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9170f13
    • Lv Yunlong's avatar
      net/rds: Fix a use after free in rds_message_map_pages · bdc2ab5c
      Lv Yunlong authored
      In rds_message_map_pages, the rm is freed by rds_message_put(rm).
      But rm is still used by rm->data.op_sg in return value.
      
      My patch assigns ERR_CAST(rm->data.op_sg) to err before the rm is
      freed to avoid the uaf.
      
      Fixes: 7dba9203 ("net/rds: Use ERR_PTR for rds_message_alloc_sgs()")
      Signed-off-by: default avatarLv Yunlong <lyl2019@mail.ustc.edu.cn>
      Reviewed-by: default avatarHåkon Bugge <haakon.bugge@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bdc2ab5c
    • Tong Zhu's avatar
      neighbour: Disregard DEAD dst in neigh_update · d47ec7a0
      Tong Zhu authored
      After a short network outage, the dst_entry is timed out and put
      in DST_OBSOLETE_DEAD. We are in this code because arp reply comes
      from this neighbour after network recovers. There is a potential
      race condition that dst_entry is still in DST_OBSOLETE_DEAD.
      With that, another neighbour lookup causes more harm than good.
      
      In best case all packets in arp_queue are lost. This is
      counterproductive to the original goal of finding a better path
      for those packets.
      
      I observed a worst case with 4.x kernel where a dst_entry in
      DST_OBSOLETE_DEAD state is associated with loopback net_device.
      It leads to an ethernet header with all zero addresses.
      A packet with all zero source MAC address is quite deadly with
      mac80211, ath9k and 802.11 block ack.  It fails
      ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). Ath9k flushes tx
      queue (ath_tx_complete_aggr). BAW (block ack window) is not
      updated. BAW logic is damaged and ath9k transmission is disabled.
      Signed-off-by: default avatarTong Zhu <zhutong@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d47ec7a0
    • Tariq Toukan's avatar
      net/mlx5e: Guarantee room for XSK wakeup NOP on async ICOSQ · 3ff3874f
      Tariq Toukan authored
      XSK wakeup flow triggers an IRQ by posting a NOP WQE and hitting
      the doorbell on the async ICOSQ.
      It maintains its state so that it doesn't issue another NOP WQE
      if it has an outstanding one already.
      
      For this flow to work properly, the NOP post must not fail.
      Make sure to reserve room for the NOP WQE in all WQE posts to the
      async ICOSQ.
      
      Fixes: 8d94b590 ("net/mlx5e: Turn XSK ICOSQ into a general asynchronous one")
      Fixes: 1182f365 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
      Fixes: 0419d8c9 ("net/mlx5e: kTLS, Add kTLS RX resync support")
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      3ff3874f
    • Dima Chumak's avatar
      net/mlx5e: Consider geneve_opts for encap contexts · 929a2fad
      Dima Chumak authored
      Current algorithm for encap keys is legacy from initial vxlan
      implementation and doesn't take into account all possible fields of a
      tunnel. For example, for a Geneve tunnel, which may have additional TLV
      options, they are ignored when comparing encap keys and a rule can be
      attached to an incorrect encap entry.
      
      Fix that by introducing encap_info_equal() operation in
      struct mlx5e_tc_tunnel. Geneve tunnel type uses custom implementation,
      which extends generic algorithm and considers options if they are set.
      
      Fixes: 7f1a546e ("net/mlx5e: Consider tunnel type for encap contexts")
      Signed-off-by: default avatarDima Chumak <dchumak@nvidia.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      929a2fad
    • Daniel Jurgens's avatar
      net/mlx5: Don't request more than supported EQs · a7b76002
      Daniel Jurgens authored
      Calculating the number of compeltion EQs based on the number of
      available IRQ vectors doesn't work now that all async EQs share one IRQ.
      Thus the max number of EQs can be exceeded on systems with more than
      approximately 256 CPUs. Take this into account when calculating the
      number of available completion EQs.
      
      Fixes: 81bfa206 ("net/mlx5: Use a single IRQ for all async EQs")
      Signed-off-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: default avatarParav Pandit <parav@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      a7b76002
    • Tariq Toukan's avatar
      net/mlx5e: kTLS, Fix RX counters atomicity · 6f4fdd53
      Tariq Toukan authored
      Some TLS RX counters increment per socket/connection, and are not
      protected against parallel modifications from several cores.
      Switch them to atomic counters by taking them out of the RQ stats into
      the global atomic TLS stats.
      
      In this patch, we touch 'rx_tls_ctx/del' that count the number of
      device-offloaded RX TLS connections added/deleted.
      These counters are updated in the add/del callbacks, out of the fast
      data-path.
      
      This change is not needed for counters that increment only in NAPI
      context, as they are protected by the NAPI mechanism.
      Keep them as tls_* counters under 'struct mlx5e_rq_stats'.
      
      Fixes: 76c1e1ac ("net/mlx5e: kTLS, Add kTLS RX stats")
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      6f4fdd53
    • Tariq Toukan's avatar
      net/mlx5e: kTLS, Fix TX counters atomicity · a51bce96
      Tariq Toukan authored
      Some TLS TX counters increment per socket/connection, and are not
      protected against parallel modifications from several cores.
      Switch them to atomic counters by taking them out of the SQ stats into
      the global atomic TLS stats.
      
      In this patch, we touch a single counter 'tx_tls_ctx' that counts the
      number of device-offloaded TX TLS connections added.
      Now that this counter can be increased without the for having the SQ
      context in hand, move it to the mlx5e_ktls_add_tx() callback where it
      really belongs, out of the fast data-path.
      
      This change is not needed for counters that increment only in NAPI
      context or under the TX lock, as they are already protected.
      Keep them as tls_* counters under 'struct mlx5e_sq_stats'.
      
      Fixes: d2ead1f3 ("net/mlx5e: Add kTLS TX HW offload support")
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      a51bce96