An error occurred fetching the project authors.
  1. 16 Nov, 2022 1 commit
  2. 25 Nov, 2021 2 commits
  3. 16 Nov, 2021 2 commits
  4. 31 Aug, 2021 1 commit
    • Eric Dumazet's avatar
      fou: remove sparse errors · 8d65cd8d
      Eric Dumazet authored
      We need to add __rcu qualifier to avoid these errors:
      
      net/ipv4/fou.c:250:18: warning: incorrect type in assignment (different address spaces)
      net/ipv4/fou.c:250:18:    expected struct net_offload const **offloads
      net/ipv4/fou.c:250:18:    got struct net_offload const [noderef] __rcu **
      net/ipv4/fou.c:251:15: error: incompatible types in comparison expression (different address spaces):
      net/ipv4/fou.c:251:15:    struct net_offload const [noderef] __rcu *
      net/ipv4/fou.c:251:15:    struct net_offload const *
      net/ipv4/fou.c:272:18: warning: incorrect type in assignment (different address spaces)
      net/ipv4/fou.c:272:18:    expected struct net_offload const **offloads
      net/ipv4/fou.c:272:18:    got struct net_offload const [noderef] __rcu **
      net/ipv4/fou.c:273:15: error: incompatible types in comparison expression (different address spaces):
      net/ipv4/fou.c:273:15:    struct net_offload const [noderef] __rcu *
      net/ipv4/fou.c:273:15:    struct net_offload const *
      net/ipv4/fou.c:442:18: warning: incorrect type in assignment (different address spaces)
      net/ipv4/fou.c:442:18:    expected struct net_offload const **offloads
      net/ipv4/fou.c:442:18:    got struct net_offload const [noderef] __rcu **
      net/ipv4/fou.c:443:15: error: incompatible types in comparison expression (different address spaces):
      net/ipv4/fou.c:443:15:    struct net_offload const [noderef] __rcu *
      net/ipv4/fou.c:443:15:    struct net_offload const *
      net/ipv4/fou.c:489:18: warning: incorrect type in assignment (different address spaces)
      net/ipv4/fou.c:489:18:    expected struct net_offload const **offloads
      net/ipv4/fou.c:489:18:    got struct net_offload const [noderef] __rcu **
      net/ipv4/fou.c:490:15: error: incompatible types in comparison expression (different address spaces):
      net/ipv4/fou.c:490:15:    struct net_offload const [noderef] __rcu *
      net/ipv4/fou.c:490:15:    struct net_offload const *
      net/ipv4/udp_offload.c:170:26: warning: incorrect type in assignment (different address spaces)
      net/ipv4/udp_offload.c:170:26:    expected struct net_offload const **offloads
      net/ipv4/udp_offload.c:170:26:    got struct net_offload const [noderef] __rcu **
      net/ipv4/udp_offload.c:171:23: error: incompatible types in comparison expression (different address spaces):
      net/ipv4/udp_offload.c:171:23:    struct net_offload const [noderef] __rcu *
      net/ipv4/udp_offload.c:171:23:    struct net_offload const *
      
      Fixes: efc98d08 ("fou: eliminate IPv4,v6 specific GRO functions")
      Fixes: 8bce6d7d ("udp: Generalize skb_udp_segment")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d65cd8d
  5. 02 Aug, 2021 1 commit
    • Jakub Sitnicki's avatar
      net, gro: Set inner transport header offset in tcp/udp GRO hook · d51c5907
      Jakub Sitnicki authored
      GSO expects inner transport header offset to be valid when
      skb->encapsulation flag is set. GSO uses this value to calculate the length
      of an individual segment of a GSO packet in skb_gso_transport_seglen().
      
      However, tcp/udp gro_complete callbacks don't update the
      skb->inner_transport_header when processing an encapsulated TCP/UDP
      segment. As a result a GRO skb has ->inner_transport_header set to a value
      carried over from earlier skb processing.
      
      This can have mild to tragic consequences. From miscalculating the GSO
      segment length to triggering a page fault [1], when trying to read TCP/UDP
      header at an address past the skb->data page.
      
      The latter scenario leads to an oops report like so:
      
        BUG: unable to handle page fault for address: ffff9fa7ec00d008
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        PGD 123f201067 P4D 123f201067 PUD 123f209067 PMD 0
        Oops: 0000 [#1] SMP NOPTI
        CPU: 44 PID: 0 Comm: swapper/44 Not tainted 5.4.53-cloudflare-2020.7.21 #1
        Hardware name: HYVE EDGE-METAL-GEN10/HS-1811DLite1, BIOS V2.15 02/21/2020
        RIP: 0010:skb_gso_transport_seglen+0x44/0xa0
        Code: c0 41 83 e0 11 f6 87 81 00 00 00 20 74 30 0f b7 87 aa 00 00 00 0f [...]
        RSP: 0018:ffffad8640bacbb8 EFLAGS: 00010202
        RAX: 000000000000feda RBX: ffff9fcc8d31bc00 RCX: ffff9fa7ec00cffc
        RDX: ffff9fa7ebffdec0 RSI: 000000000000feda RDI: 0000000000000122
        RBP: 00000000000005c4 R08: 0000000000000001 R09: 0000000000000000
        R10: ffff9fe588ae3800 R11: ffff9fe011fc92f0 R12: ffff9fcc8d31bc00
        R13: ffff9fe0119d4300 R14: 00000000000005c4 R15: ffff9fba57d70900
        FS:  0000000000000000(0000) GS:ffff9fe68df00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: ffff9fa7ec00d008 CR3: 0000003e99b1c000 CR4: 0000000000340ee0
        Call Trace:
         <IRQ>
         skb_gso_validate_network_len+0x11/0x70
         __ip_finish_output+0x109/0x1c0
         ip_sublist_rcv_finish+0x57/0x70
         ip_sublist_rcv+0x2aa/0x2d0
         ? ip_rcv_finish_core.constprop.0+0x390/0x390
         ip_list_rcv+0x12b/0x14f
         __netif_receive_skb_list_core+0x2a9/0x2d0
         netif_receive_skb_list_internal+0x1b5/0x2e0
         napi_complete_done+0x93/0x140
         veth_poll+0xc0/0x19f [veth]
         ? mlx5e_napi_poll+0x221/0x610 [mlx5_core]
         net_rx_action+0x1f8/0x790
         __do_softirq+0xe1/0x2bf
         irq_exit+0x8e/0xc0
         do_IRQ+0x58/0xe0
         common_interrupt+0xf/0xf
         </IRQ>
      
      The bug can be observed in a simple setup where we send IP/GRE/IP/TCP
      packets into a netns over a veth pair. Inside the netns, packets are
      forwarded to dummy device:
      
        trafgen -> [veth A]--[veth B] -forward-> [dummy]
      
      For veth B to GRO aggregate packets on receive, it needs to have an XDP
      program attached (for example, a trivial XDP_PASS). Additionally, for UDP,
      we need to enable GSO_UDP_L4 feature on the device:
      
        ip netns exec A ethtool -K AB rx-udp-gro-forwarding on
      
      The last component is an artificial delay to increase the chances of GRO
      batching happening:
      
        ip netns exec A tc qdisc add dev AB root \
           netem delay 200us slot 5ms 10ms packets 2 bytes 64k
      
      With such a setup in place, the bug can be observed by tracing the skb
      outer and inner offsets when GSO skb is transmitted from the dummy device:
      
      tcp:
      
      FUNC              DEV   SKB_LEN  NH  TH ENC INH ITH GSO_SIZE GSO_TYPE
      ip_finish_output  dumB     2830 270 290   1 294 254     1383 (tcpv4,gre,)
                                                      ^^^
      udp:
      
      FUNC              DEV   SKB_LEN  NH  TH ENC INH ITH GSO_SIZE GSO_TYPE
      ip_finish_output  dumB     2818 270 290   1 294 254     1383 (gre,udp_l4,)
                                                      ^^^
      
      Fix it by updating the inner transport header offset in tcp/udp
      gro_complete callbacks, similar to how {inet,ipv6}_gro_complete callbacks
      update the inner network header offset, when skb->encapsulation flag is
      set.
      
      [1] https://lore.kernel.org/netdev/CAKxSbF01cLpZem2GFaUaifh0S-5WYViZemTicAg7FCHOnh6kug@mail.gmail.com/
      
      Fixes: bf296b12 ("tcp: Add GRO support")
      Fixes: f993bc25 ("net: core: handle encapsulation offloads when computing segment lengths")
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Reported-by: default avatarAlex Forster <aforster@cloudflare.com>
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d51c5907
  6. 02 Jul, 2021 1 commit
  7. 31 Mar, 2021 2 commits
    • Paolo Abeni's avatar
      udp: properly complete L4 GRO over UDP tunnel packet · e0e3070a
      Paolo Abeni authored
      After the previous patch, the stack can do L4 UDP aggregation
      on top of a UDP tunnel.
      
      In such scenario, udp{4,6}_gro_complete will be called twice. This function
      will enter its is_flist branch immediately, even though that is only
      correct on the second call, as GSO_FRAGLIST is only relevant for the
      inner packet.
      
      Instead, we need to try first UDP tunnel-based aggregation, if the GRO
      packet requires that.
      
      This patch changes udp{4,6}_gro_complete to skip the frag list processing
      when while encap_mark == 1, identifying processing of the outer tunnel
      header.
      Additionally, clears the field in udp_gro_complete() so that we can enter
      the frag list path on the next round, for the inner header.
      
      v1 -> v2:
       - hopefully clarified the commit message
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0e3070a
    • Paolo Abeni's avatar
      udp: skip L4 aggregation for UDP tunnel packets · 18f25dc3
      Paolo Abeni authored
      If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
      are UDP tunnels available in the system, udp_gro_receive() could end-up
      doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
      the outer UDP tunnel level for packets effectively carrying and UDP
      tunnel header.
      
      That could cause inner protocol corruption. If e.g. the relevant
      packets carry a vxlan header, different vxlan ids will be ignored/
      aggregated to the same GSO packet. Inner headers will be ignored, too,
      so that e.g. TCP over vxlan push packets will be held in the GRO
      engine till the next flush, etc.
      
      Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
      current packet could land in a UDP tunnel, and let udp_gro_receive()
      do GRO via udp_sk(sk)->gro_receive.
      
      The check implemented in this patch is broader than what is strictly
      needed, as the existing UDP tunnel could be e.g. configured on top of
      a different device: we could end-up skipping GRO at-all for some packets.
      
      Anyhow, that is a very thin corner case and covering it will add quite
      a bit of complexity.
      
      v1 -> v2:
       - hopefully clarify the commit message
      
      Fixes: 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.")
      Fixes: 36707061 ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18f25dc3
  8. 28 Feb, 2021 1 commit
    • Daniel Borkmann's avatar
      net: Fix gro aggregation for udp encaps with zero csum · 89e5c58f
      Daniel Borkmann authored
      We noticed a GRO issue for UDP-based encaps such as vxlan/geneve when the
      csum for the UDP header itself is 0. In that case, GRO aggregation does
      not take place on the phys dev, but instead is deferred to the vxlan/geneve
      driver (see trace below).
      
      The reason is essentially that GRO aggregation bails out in udp_gro_receive()
      for such case when drivers marked the skb with CHECKSUM_UNNECESSARY (ice, i40e,
      others) where for non-zero csums 2abb7cdc ("udp: Add support for doing
      checksum unnecessary conversion") promotes those skbs to CHECKSUM_COMPLETE
      and napi context has csum_valid set. This is however not the case for zero
      UDP csum (here: csum_cnt is still 0 and csum_valid continues to be false).
      
      At the same time 57c67ff4 ("udp: additional GRO support") added matches
      on !uh->check ^ !uh2->check as part to determine candidates for aggregation,
      so it certainly is expected to handle zero csums in udp_gro_receive(). The
      purpose of the check added via 662880f4 ("net: Allow GRO to use and set
      levels of checksum unnecessary") seems to catch bad csum and stop aggregation
      right away.
      
      One way to fix aggregation in the zero case is to only perform the !csum_valid
      check in udp_gro_receive() if uh->check is infact non-zero.
      
      Before:
      
        [...]
        swapper     0 [008]   731.946506: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100400 len=1500   (1)
        swapper     0 [008]   731.946507: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100200 len=1500
        swapper     0 [008]   731.946507: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101100 len=1500
        swapper     0 [008]   731.946508: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101700 len=1500
        swapper     0 [008]   731.946508: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101b00 len=1500
        swapper     0 [008]   731.946508: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100600 len=1500
        swapper     0 [008]   731.946508: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100f00 len=1500
        swapper     0 [008]   731.946509: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100a00 len=1500
        swapper     0 [008]   731.946516: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100500 len=1500
        swapper     0 [008]   731.946516: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100700 len=1500
        swapper     0 [008]   731.946516: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101d00 len=1500   (2)
        swapper     0 [008]   731.946517: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101000 len=1500
        swapper     0 [008]   731.946517: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101c00 len=1500
        swapper     0 [008]   731.946517: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101400 len=1500
        swapper     0 [008]   731.946518: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100e00 len=1500
        swapper     0 [008]   731.946518: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497101600 len=1500
        swapper     0 [008]   731.946521: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff966497100800 len=774
        swapper     0 [008]   731.946530: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff966497100400 len=14032 (1)
        swapper     0 [008]   731.946530: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff966497101d00 len=9112  (2)
        [...]
      
        # netperf -H 10.55.10.4 -t TCP_STREAM -l 20
        MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.55.10.4 () port 0 AF_INET : demo
        Recv   Send    Send
        Socket Socket  Message  Elapsed
        Size   Size    Size     Time     Throughput
        bytes  bytes   bytes    secs.    10^6bits/sec
      
         87380  16384  16384    20.01    13129.24
      
      After:
      
        [...]
        swapper     0 [026]   521.862641: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff93ab0d479000 len=11286 (1)
        swapper     0 [026]   521.862643: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d479000 len=11236 (1)
        swapper     0 [026]   521.862650: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff93ab0d478500 len=2898  (2)
        swapper     0 [026]   521.862650: net:netif_receive_skb: dev=enp10s0f0  skbaddr=0xffff93ab0d479f00 len=8490  (3)
        swapper     0 [026]   521.862653: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d478500 len=2848  (2)
        swapper     0 [026]   521.862653: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d479f00 len=8440  (3)
        [...]
      
        # netperf -H 10.55.10.4 -t TCP_STREAM -l 20
        MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.55.10.4 () port 0 AF_INET : demo
        Recv   Send    Send
        Socket Socket  Message  Elapsed
        Size   Size    Size     Time     Throughput
        bytes  bytes   bytes    secs.    10^6bits/sec
      
         87380  16384  16384    20.01    24576.53
      
      Fixes: 57c67ff4 ("udp: additional GRO support")
      Fixes: 662880f4 ("net: Allow GRO to use and set levels of checksum unnecessary")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/r/20210226212248.8300-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      89e5c58f
  9. 02 Feb, 2021 1 commit
  10. 24 Jan, 2021 1 commit
    • Alexander Lobakin's avatar
      udp: allow forwarding of plain (non-fraglisted) UDP GRO packets · 36707061
      Alexander Lobakin authored
      Commit 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.") actually
      not only added a support for fraglisted UDP GRO, but also tweaked
      some logics the way that non-fraglisted UDP GRO started to work for
      forwarding too.
      Commit 2e4ef10f ("net: add GSO UDP L4 and GSO fraglists to the
      list of software-backed types") added GSO UDP L4 to the list of
      software GSO to allow virtual netdevs to forward them as is up to
      the real drivers.
      
      Tests showed that currently forwarding and NATing of plain UDP GRO
      packets are performed fully correctly, regardless if the target
      netdevice has a support for hardware/driver GSO UDP L4 or not.
      Add the last element and allow to form plain UDP GRO packets if
      we are on forwarding path, and the new NETIF_F_GRO_UDP_FWD is
      enabled on a receiving netdevice.
      
      If both NETIF_F_GRO_FRAGLIST and NETIF_F_GRO_UDP_FWD are set,
      fraglisted GRO takes precedence. This keeps the current behaviour
      and is generally more optimal for now, as the number of NICs with
      hardware USO offload is relatively small.
      Signed-off-by: default avatarAlexander Lobakin <alobakin@pm.me>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      36707061
  11. 21 Jan, 2021 1 commit
  12. 12 Nov, 2020 3 commits
  13. 30 Oct, 2020 1 commit
    • Xin Long's avatar
      udp: support sctp over udp in skb_udp_tunnel_segment · 527beb8e
      Xin Long authored
      For the gso of sctp over udp packets, sctp_gso_segment() will be called in
      skb_udp_tunnel_segment(), we need to set transport_header to sctp header.
      
      As all the current HWs can't handle both crc checksum and udp checksum at
      the same time, the crc checksum has to be done in sctp_gso_segment() by
      removing the NETIF_F_SCTP_CRC flag from the features.
      
      Meanwhile, if the HW can't do udp checksum, csum and csum_start has to be
      set correctly, and udp checksum will be done in __skb_udp_tunnel_segment()
      by calling gso_make_checksum().
      
      Thanks to Paolo, Marcelo and Guillaume for helping with this one.
      
      v1->v2:
        - no change.
      v2->v3:
        - remove the he NETIF_F_SCTP_CRC flag from the features.
        - set csum and csum_start in sctp_gso_make_checksum().
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      527beb8e
  14. 30 Mar, 2020 1 commit
  15. 27 Jan, 2020 1 commit
  16. 03 Jan, 2020 1 commit
  17. 19 Jun, 2019 1 commit
    • Fred Klassen's avatar
      net/udp_gso: Allow TX timestamp with UDP GSO · 76e21533
      Fred Klassen authored
      Fixes an issue where TX Timestamps are not arriving on the error queue
      when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING.
      This can be illustrated with an updated updgso_bench_tx program which
      includes the '-T' option to test for this condition. It also introduces
      the '-P' option which will call poll() before reading the error queue.
      
          ./udpgso_bench_tx -4ucTPv -S 1472 -l2 -D 172.16.120.18
          poll timeout
          udp tx:      0 MB/s        1 calls/s      1 msg/s
      
      The "poll timeout" message above indicates that TX timestamp never
      arrived.
      
      This patch preserves tx_flags for the first UDP GSO segment. Only the
      first segment is timestamped, even though in some cases there may be
      benefital in timestamping both the first and last segment.
      
      Factors in deciding on first segment timestamp only:
      
      - Timestamping both first and last segmented is not feasible. Hardware
      can only have one outstanding TS request at a time.
      
      - Timestamping last segment may under report network latency of the
      previous segments. Even though the doorbell is suppressed, the ring
      producer counter has been incremented.
      
      - Timestamping the first segment has the upside in that it reports
      timestamps from the application's view, e.g. RTT.
      
      - Timestamping the first segment has the downside that it may
      underreport tx host network latency. It appears that we have to pick
      one or the other. And possibly follow-up with a config flag to choose
      behavior.
      
      v2: Remove tests as noted by Willem de Bruijn <willemb@google.com>
          Moving tests from net to net-next
      
      v3: Update only relevant tx_flag bits as per
          Willem de Bruijn <willemb@google.com>
      
      v4: Update comments and commit message as per
          Willem de Bruijn <willemb@google.com>
      
      Fixes: ee80d1eb ("udp: add udp gso")
      Signed-off-by: default avatarFred Klassen <fklassen@appneta.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76e21533
  18. 05 Jun, 2019 1 commit
  19. 30 May, 2019 1 commit
  20. 02 May, 2019 1 commit
    • Eric Dumazet's avatar
      udp: fix GRO packet of death · 4dd2b82d
      Eric Dumazet authored
      syzbot was able to crash host by sending UDP packets with a 0 payload.
      
      TCP does not have this issue since we do not aggregate packets without
      payload.
      
      Since dev_gro_receive() sets gso_size based on skb_gro_len(skb)
      it seems not worth trying to cope with padded packets.
      
      BUG: KASAN: slab-out-of-bounds in skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826
      Read of size 16 at addr ffff88808893fff0 by task syz-executor612/7889
      
      CPU: 0 PID: 7889 Comm: syz-executor612 Not tainted 5.1.0-rc7+ #96
      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:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_load16_noabort+0x14/0x20 mm/kasan/generic_report.c:133
       skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826
       udp_gro_receive_segment net/ipv4/udp_offload.c:382 [inline]
       call_gro_receive include/linux/netdevice.h:2349 [inline]
       udp_gro_receive+0xb61/0xfd0 net/ipv4/udp_offload.c:414
       udp4_gro_receive+0x763/0xeb0 net/ipv4/udp_offload.c:478
       inet_gro_receive+0xe72/0x1110 net/ipv4/af_inet.c:1510
       dev_gro_receive+0x1cd0/0x23c0 net/core/dev.c:5581
       napi_gro_frags+0x36b/0xd10 net/core/dev.c:5843
       tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027
       call_write_iter include/linux/fs.h:1866 [inline]
       do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681
       do_iter_write fs/read_write.c:957 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:938
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002
       do_writev+0x15e/0x370 fs/read_write.c:1037
       __do_sys_writev fs/read_write.c:1110 [inline]
       __se_sys_writev fs/read_write.c:1107 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x441cc0
      Code: 05 48 3d 01 f0 ff ff 0f 83 9d 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 3d 51 93 29 00 00 75 14 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 74 09 fc ff c3 48 83 ec 08 e8 ba 2b 00 00
      RSP: 002b:00007ffe8c716118 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 00007ffe8c716150 RCX: 0000000000441cc0
      RDX: 0000000000000001 RSI: 00007ffe8c716170 RDI: 00000000000000f0
      RBP: 0000000000000000 R08: 000000000000ffff R09: 0000000000a64668
      R10: 0000000020000040 R11: 0000000000000246 R12: 000000000000c2d9
      R13: 0000000000402b50 R14: 0000000000000000 R15: 0000000000000000
      
      Allocated by task 5143:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_kmalloc mm/kasan/common.c:497 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
       kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:505
       slab_post_alloc_hook mm/slab.h:437 [inline]
       slab_alloc mm/slab.c:3393 [inline]
       kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3555
       mm_alloc+0x1d/0xd0 kernel/fork.c:1030
       bprm_mm_init fs/exec.c:363 [inline]
       __do_execve_file.isra.0+0xaa3/0x23f0 fs/exec.c:1791
       do_execveat_common fs/exec.c:1865 [inline]
       do_execve fs/exec.c:1882 [inline]
       __do_sys_execve fs/exec.c:1958 [inline]
       __se_sys_execve fs/exec.c:1953 [inline]
       __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 5351:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:467
       __cache_free mm/slab.c:3499 [inline]
       kmem_cache_free+0x86/0x260 mm/slab.c:3765
       __mmdrop+0x238/0x320 kernel/fork.c:677
       mmdrop include/linux/sched/mm.h:49 [inline]
       finish_task_switch+0x47b/0x780 kernel/sched/core.c:2746
       context_switch kernel/sched/core.c:2880 [inline]
       __schedule+0x81b/0x1cc0 kernel/sched/core.c:3518
       preempt_schedule_irq+0xb5/0x140 kernel/sched/core.c:3745
       retint_kernel+0x1b/0x2d
       arch_local_irq_restore arch/x86/include/asm/paravirt.h:767 [inline]
       kmem_cache_free+0xab/0x260 mm/slab.c:3766
       anon_vma_chain_free mm/rmap.c:134 [inline]
       unlink_anon_vmas+0x2ba/0x870 mm/rmap.c:401
       free_pgtables+0x1af/0x2f0 mm/memory.c:394
       exit_mmap+0x2d1/0x530 mm/mmap.c:3144
       __mmput kernel/fork.c:1046 [inline]
       mmput+0x15f/0x4c0 kernel/fork.c:1067
       exec_mmap fs/exec.c:1046 [inline]
       flush_old_exec+0x8d9/0x1c20 fs/exec.c:1279
       load_elf_binary+0x9bc/0x53f0 fs/binfmt_elf.c:864
       search_binary_handler fs/exec.c:1656 [inline]
       search_binary_handler+0x17f/0x570 fs/exec.c:1634
       exec_binprm fs/exec.c:1698 [inline]
       __do_execve_file.isra.0+0x1394/0x23f0 fs/exec.c:1818
       do_execveat_common fs/exec.c:1865 [inline]
       do_execve fs/exec.c:1882 [inline]
       __do_sys_execve fs/exec.c:1958 [inline]
       __se_sys_execve fs/exec.c:1953 [inline]
       __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff88808893f7c0
       which belongs to the cache mm_struct of size 1496
      The buggy address is located 600 bytes to the right of
       1496-byte region [ffff88808893f7c0, ffff88808893fd98)
      The buggy address belongs to the page:
      page:ffffea0002224f80 count:1 mapcount:0 mapping:ffff88821bc40ac0 index:0xffff88808893f7c0 compound_mapcount: 0
      flags: 0x1fffc0000010200(slab|head)
      raw: 01fffc0000010200 ffffea00025b4f08 ffffea00027b9d08 ffff88821bc40ac0
      raw: ffff88808893f7c0 ffff88808893e440 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88808893fe80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88808893ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88808893ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                   ^
       ffff888088940000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff888088940080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd2b82d
  21. 28 Apr, 2019 1 commit
  22. 15 Dec, 2018 2 commits
  23. 08 Nov, 2018 1 commit
    • Paolo Abeni's avatar
      udp: implement GRO for plain UDP sockets. · e20cf8d3
      Paolo Abeni authored
      This is the RX counterpart of commit bec1f6f6 ("udp: generate gso
      with UDP_SEGMENT"). When UDP_GRO is enabled, such socket is also
      eligible for GRO in the rx path: UDP segments directed to such socket
      are assembled into a larger GSO_UDP_L4 packet.
      
      The core UDP GRO support is enabled with setsockopt(UDP_GRO).
      
      Initial benchmark numbers:
      
      Before:
      udp rx:   1079 MB/s   769065 calls/s
      
      After:
      udp rx:   1466 MB/s    24877 calls/s
      
      This change introduces a side effect in respect to UDP tunnels:
      after a UDP tunnel creation, now the kernel performs a lookup per ingress
      UDP packet, while before such lookup happened only if the ingress packet
      carried a valid internal header csum.
      
      rfc v2 -> rfc v3:
       - fixed typos in macro name and comments
       - really enforce UDP_GRO_CNT_MAX, instead of UDP_GRO_CNT_MAX + 1
       - acquire socket lock in UDP_GRO setsockopt
      
      rfc v1 -> rfc v2:
       - use a new option to enable UDP GRO
       - use static keys to protect the UDP GRO socket lookup
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e20cf8d3
  24. 05 Oct, 2018 1 commit
  25. 02 Jul, 2018 1 commit
    • Sabrina Dubroca's avatar
      net: fix use-after-free in GRO with ESP · 603d4cf8
      Sabrina Dubroca authored
      Since the addition of GRO for ESP, gro_receive can consume the skb and
      return -EINPROGRESS. In that case, the lower layer GRO handler cannot
      touch the skb anymore.
      
      Commit 5f114163 ("net: Add a skb_gro_flush_final helper.") converted
      some of the gro_receive handlers that can lead to ESP's gro_receive so
      that they wouldn't access the skb when -EINPROGRESS is returned, but
      missed other spots, mainly in tunneling protocols.
      
      This patch finishes the conversion to using skb_gro_flush_final(), and
      adds a new helper, skb_gro_flush_final_remcsum(), used in VXLAN and
      GUE.
      
      Fixes: 5f114163 ("net: Add a skb_gro_flush_final helper.")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      603d4cf8
  26. 26 Jun, 2018 1 commit
    • David Miller's avatar
      net: Convert GRO SKB handling to list_head. · d4546c25
      David Miller authored
      Manage pending per-NAPI GRO packets via list_head.
      
      Return an SKB pointer from the GRO receive handlers.  When GRO receive
      handlers return non-NULL, it means that this SKB needs to be completed
      at this time and removed from the NAPI queue.
      
      Several operations are greatly simplified by this transformation,
      especially timing out the oldest SKB in the list when gro_count
      exceeds MAX_GRO_SKBS, and napi_gro_flush() which walks the queue
      in reverse order.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4546c25
  27. 11 May, 2018 1 commit
    • Eric Dumazet's avatar
      udp: avoid refcount_t saturation in __udp_gso_segment() · 575b65bc
      Eric Dumazet authored
      For some reason, Willem thought that the issue we fixed for TCP
      in commit 7ec318fe ("tcp: gso: avoid refcount_t warning from
      tcp_gso_segment()") was not relevant for UDP GSO.
      
      But syzbot found its way.
      
      refcount_t: saturated; leaking memory.
      WARNING: CPU: 0 PID: 10261 at lib/refcount.c:78 refcount_add_not_zero+0x2d4/0x320 lib/refcount.c:78
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 0 PID: 10261 Comm: syz-executor5 Not tainted 4.17.0-rc3+ #38
      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+0x1b9/0x294 lib/dump_stack.c:113
       panic+0x22f/0x4de kernel/panic.c:184
       __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
       report_bug+0x252/0x2d0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:178 [inline]
       do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
       do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
      RIP: 0010:refcount_add_not_zero+0x2d4/0x320 lib/refcount.c:78
      RSP: 0018:ffff880196db6b90 EFLAGS: 00010282
      RAX: 0000000000000026 RBX: 00000000ffffff01 RCX: ffffc900040d9000
      RDX: 0000000000004a29 RSI: ffffffff8160f6f1 RDI: ffff880196db66f0
      RBP: ffff880196db6c78 R08: ffff8801b33d6740 R09: 0000000000000002
      R10: ffff8801b33d6740 R11: 0000000000000000 R12: 0000000000000000
      R13: 00000000ffffffff R14: ffff880196db6c50 R15: 0000000000020101
       refcount_add+0x1b/0x70 lib/refcount.c:102
       __udp_gso_segment+0xaa5/0xee0 net/ipv4/udp_offload.c:272
       udp4_ufo_fragment+0x592/0x7a0 net/ipv4/udp_offload.c:301
       inet_gso_segment+0x639/0x12b0 net/ipv4/af_inet.c:1342
       skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
       __skb_gso_segment+0x3bb/0x870 net/core/dev.c:2865
       skb_gso_segment include/linux/netdevice.h:4050 [inline]
       validate_xmit_skb+0x54d/0xd90 net/core/dev.c:3122
       __dev_queue_xmit+0xbf8/0x34c0 net/core/dev.c:3579
       dev_queue_xmit+0x17/0x20 net/core/dev.c:3620
       neigh_direct_output+0x15/0x20 net/core/neighbour.c:1401
       neigh_output include/net/neighbour.h:483 [inline]
       ip_finish_output2+0xa5f/0x1840 net/ipv4/ip_output.c:229
       ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
       NF_HOOK_COND include/linux/netfilter.h:277 [inline]
       ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
       dst_output include/net/dst.h:444 [inline]
       ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
       ip_send_skb+0x40/0xe0 net/ipv4/ip_output.c:1434
       udp_send_skb.isra.37+0x5eb/0x1000 net/ipv4/udp.c:825
       udp_push_pending_frames+0x5c/0xf0 net/ipv4/udp.c:853
       udp_v6_push_pending_frames+0x380/0x3e0 net/ipv6/udp.c:1105
       udp_lib_setsockopt+0x59a/0x600 net/ipv4/udp.c:2403
       udpv6_setsockopt+0x95/0xa0 net/ipv6/udp.c:1447
       sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3046
       __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
       __do_sys_setsockopt net/socket.c:1914 [inline]
       __se_sys_setsockopt net/socket.c:1911 [inline]
       __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
       do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: ad405857 ("udp: better wmem accounting on gso")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Cc: Alexander Duyck <alexander.h.duyck@intel.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      575b65bc
  28. 09 May, 2018 5 commits
  29. 02 May, 2018 1 commit
  30. 28 Apr, 2018 1 commit