1. 21 6月, 2021 1 次提交
  2. 10 6月, 2021 1 次提交
  3. 02 4月, 2021 3 次提交
  4. 31 3月, 2021 2 次提交
    • P
      udp: never accept GSO_FRAGLIST packets · 78352f73
      Paolo Abeni 提交于
      Currently the UDP protocol delivers GSO_FRAGLIST packets to
      the sockets without the expected segmentation.
      
      This change addresses the issue introducing and maintaining
      a couple of new fields to explicitly accept SKB_GSO_UDP_L4
      or GSO_FRAGLIST packets. Additionally updates  udp_unexpected_gso()
      accordingly.
      
      UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist
      zeroed.
      
      v1 -> v2:
       - use 2 bits instead of a whole GSO bitmask (Willem)
      
      Fixes: 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78352f73
    • P
      udp: fixup csum for GSO receive slow path · 000ac44d
      Paolo Abeni 提交于
      When UDP packets generated locally by a socket with UDP_SEGMENT
      traverse the following path:
      
      UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) ->
      	UDP tunnel (rx) -> UDP socket (no UDP_GRO)
      
      ip_summed will be set to CHECKSUM_PARTIAL at creation time and
      such checksum mode will be preserved in the above path up to the
      UDP tunnel receive code where we have:
      
       __iptunnel_pull_header() -> skb_pull_rcsum() ->
      skb_postpull_rcsum() -> __skb_postpull_rcsum()
      
      The latter will convert the skb to CHECKSUM_NONE.
      
      The UDP GSO packet will be later segmented as part of the rx socket
      receive operation, and will present a CHECKSUM_NONE after segmentation.
      
      Additionally the segmented packets UDP CB still refers to the original
      GSO packet len. Overall that causes unexpected/wrong csum validation
      errors later in the UDP receive path.
      
      We could possibly address the issue with some additional checks and
      csum mangling in the UDP tunnel code. Since the issue affects only
      this UDP receive slow path, let's set a suitable csum status there.
      
      Note that SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST packets lacking an UDP
      encapsulation present a valid checksum when landing to udp_queue_rcv_skb(),
      as the UDP checksum has been validated by the GRO engine.
      
      v2 -> v3:
       - even more verbose commit message and comments
      
      v1 -> v2:
       - restrict the csum update to the packets strictly needing them
       - hopefully clarify the commit message and code comments
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      000ac44d
  5. 05 2月, 2021 1 次提交
  6. 21 1月, 2021 1 次提交
  7. 20 1月, 2021 1 次提交
    • G
      udp: mask TOS bits in udp_v4_early_demux() · 8d2b51b0
      Guillaume Nault 提交于
      udp_v4_early_demux() is the only function that calls
      ip_mc_validate_source() with a TOS that hasn't been masked with
      IPTOS_RT_MASK.
      
      This results in different behaviours for incoming multicast UDPv4
      packets, depending on if ip_mc_validate_source() is called from the
      early-demux path (udp_v4_early_demux) or from the regular input path
      (ip_route_input_noref).
      
      ECN would normally not be used with UDP multicast packets, so the
      practical consequences should be limited on that side. However,
      IPTOS_RT_MASK is used to also masks the TOS' high order bits, to align
      with the non-early-demux path behaviour.
      
      Reproducer:
      
        Setup two netns, connected with veth:
        $ ip netns add ns0
        $ ip netns add ns1
        $ ip -netns ns0 link set dev lo up
        $ ip -netns ns1 link set dev lo up
        $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1
        $ ip -netns ns0 link set dev veth01 up
        $ ip -netns ns1 link set dev veth10 up
        $ ip -netns ns0 address add 192.0.2.10 peer 192.0.2.11/32 dev veth01
        $ ip -netns ns1 address add 192.0.2.11 peer 192.0.2.10/32 dev veth10
      
        In ns0, add route to multicast address 224.0.2.0/24 using source
        address 198.51.100.10:
        $ ip -netns ns0 address add 198.51.100.10/32 dev lo
        $ ip -netns ns0 route add 224.0.2.0/24 dev veth01 src 198.51.100.10
      
        In ns1, define route to 198.51.100.10, only for packets with TOS 4:
        $ ip -netns ns1 route add 198.51.100.10/32 tos 4 dev veth10
      
        Also activate rp_filter in ns1, so that incoming packets not matching
        the above route get dropped:
        $ ip netns exec ns1 sysctl -wq net.ipv4.conf.veth10.rp_filter=1
      
        Now try to receive packets on 224.0.2.11:
        $ ip netns exec ns1 socat UDP-RECVFROM:1111,ip-add-membership=224.0.2.11:veth10,ignoreeof -
      
        In ns0, send packet to 224.0.2.11 with TOS 4 and ECT(0) (that is,
        tos 6 for socat):
        $ echo test0 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6
      
        The "test0" message is properly received by socat in ns1, because
        early-demux has no cached dst to use, so source address validation
        is done by ip_route_input_mc(), which receives a TOS that has the
        ECN bits masked.
      
        Now send another packet to 224.0.2.11, still with TOS 4 and ECT(0):
        $ echo test1 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6
      
        The "test1" message isn't received by socat in ns1, because, now,
        early-demux has a cached dst to use and calls ip_mc_validate_source()
        immediately, without masking the ECN bits.
      
      Fixes: bc044e8d ("udp: perform source validation for mcast early demux")
      Signed-off-by: NGuillaume Nault <gnault@redhat.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8d2b51b0
  8. 07 12月, 2020 1 次提交
  9. 24 11月, 2020 1 次提交
  10. 15 11月, 2020 1 次提交
  11. 11 11月, 2020 1 次提交
  12. 10 11月, 2020 2 次提交
  13. 31 10月, 2020 1 次提交
  14. 25 8月, 2020 1 次提交
  15. 31 7月, 2020 1 次提交
  16. 26 7月, 2020 2 次提交
  17. 25 7月, 2020 2 次提交
  18. 22 7月, 2020 3 次提交
  19. 20 7月, 2020 1 次提交
  20. 18 7月, 2020 2 次提交
  21. 14 7月, 2020 1 次提交
  22. 25 6月, 2020 2 次提交
  23. 28 4月, 2020 1 次提交
  24. 31 3月, 2020 1 次提交
  25. 30 3月, 2020 1 次提交
  26. 13 3月, 2020 1 次提交
  27. 29 2月, 2020 1 次提交
  28. 20 2月, 2020 1 次提交
    • W
      udp: rehash on disconnect · 303d0403
      Willem de Bruijn 提交于
      As of the below commit, udp sockets bound to a specific address can
      coexist with one bound to the any addr for the same port.
      
      The commit also phased out the use of socket hashing based only on
      port (hslot), in favor of always hashing on {addr, port} (hslot2).
      
      The change broke the following behavior with disconnect (AF_UNSPEC):
      
          server binds to 0.0.0.0:1337
          server connects to 127.0.0.1:80
          server disconnects
          client connects to 127.0.0.1:1337
          client sends "hello"
          server reads "hello"	// times out, packet did not find sk
      
      On connect the server acquires a specific source addr suitable for
      routing to its destination. On disconnect it reverts to the any addr.
      
      The connect call triggers a rehash to a different hslot2. On
      disconnect, add the same to return to the original hslot2.
      
      Skip this step if the socket is going to be unhashed completely.
      
      Fixes: 4cdeeee9 ("net: udp: prefer listeners bound to an address")
      Reported-by: NPavel Roskin <plroskin@gmail.com>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      303d0403
  29. 23 1月, 2020 1 次提交
  30. 15 1月, 2020 1 次提交