1. 03 Nov, 2020 23 commits
  2. 02 Nov, 2020 7 commits
  3. 01 Nov, 2020 3 commits
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 859191b2
      Jakub Kicinski authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for net:
      
      1) Incorrect netlink report logic in flowtable and genID.
      
      2) Add a selftest to check that wireguard passes the right sk
         to ip_route_me_harder, from Jason A. Donenfeld.
      
      3) Pass the actual sk to ip_route_me_harder(), also from Jason.
      
      4) Missing expression validation of updates via nft --check.
      
      5) Update byte and packet counters regardless of whether they
         match, from Stefano Brivio.
      ====================
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      859191b2
    • wenxu's avatar
      ip_tunnel: fix over-mtu packet send fail without TUNNEL_DONT_FRAGMENT flags · 20149e9e
      wenxu authored
      The tunnel device such as vxlan, bareudp and geneve in the lwt mode set
      the outer df only based TUNNEL_DONT_FRAGMENT.
      And this was also the behavior for gre device before switching to use
      ip_md_tunnel_xmit in commit 962924fa ("ip_gre: Refactor collect
      metatdata mode tunnel xmit to ip_md_tunnel_xmit")
      
      When the ip_gre in lwt mode xmit with ip_md_tunnel_xmi changed the rule and
      make the discrepancy between handling of DF by different tunnels. So in the
      ip_md_tunnel_xmit should follow the same rule like other tunnels.
      
      Fixes: cfc7381b ("ip_tunnel: add collect_md mode to IPIP tunnel")
      Signed-off-by: default avatarwenxu <wenxu@ucloud.cn>
      Link: https://lore.kernel.org/r/1604028728-31100-1-git-send-email-wenxu@ucloud.cnSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      20149e9e
    • Mark Deneen's avatar
      cadence: force nonlinear buffers to be cloned · 403dc167
      Mark Deneen authored
      In my test setup, I had a SAMA5D27 device configured with ip forwarding, and
      second device with usb ethernet (r8152) sending ICMP packets.  If the packet
      was larger than about 220 bytes, the SAMA5 device would "oops" with the
      following trace:
      
      kernel BUG at net/core/skbuff.c:1863!
      Internal error: Oops - BUG: 0 [#1] ARM
      Modules linked in: xt_MASQUERADE ppp_async ppp_generic slhc iptable_nat xt_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 can_raw can bridge stp llc ipt_REJECT nf_reject_ipv4 sd_mod cdc_ether usbnet usb_storage r8152 scsi_mod mii o
      ption usb_wwan usbserial micrel macb at91_sama5d2_adc phylink gpio_sama5d2_piobu m_can_platform m_can industrialio_triggered_buffer kfifo_buf of_mdio can_dev fixed_phy sdhci_of_at91 sdhci_pltfm libphy sdhci mmc_core ohci_at91 ehci_atmel o
      hci_hcd iio_rescale industrialio sch_fq_codel spidev prox2_hal(O)
      CPU: 0 PID: 0 Comm: swapper Tainted: G           O      5.9.1-prox2+ #1
      Hardware name: Atmel SAMA5
      PC is at skb_put+0x3c/0x50
      LR is at macb_start_xmit+0x134/0xad0 [macb]
      pc : [<c05258cc>]    lr : [<bf0ea5b8>]    psr: 20070113
      sp : c0d01a60  ip : c07232c0  fp : c4250000
      r10: c0d03cc8  r9 : 00000000  r8 : c0d038c0
      r7 : 00000000  r6 : 00000008  r5 : c59b66c0  r4 : 0000002a
      r3 : 8f659eff  r2 : c59e9eea  r1 : 00000001  r0 : c59b66c0
      Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c53c7d  Table: 2640c059  DAC: 00000051
      Process swapper (pid: 0, stack limit = 0x75002d81)
      
      <snipped stack>
      
      [<c05258cc>] (skb_put) from [<bf0ea5b8>] (macb_start_xmit+0x134/0xad0 [macb])
      [<bf0ea5b8>] (macb_start_xmit [macb]) from [<c053e504>] (dev_hard_start_xmit+0x90/0x11c)
      [<c053e504>] (dev_hard_start_xmit) from [<c0571180>] (sch_direct_xmit+0x124/0x260)
      [<c0571180>] (sch_direct_xmit) from [<c053eae4>] (__dev_queue_xmit+0x4b0/0x6d0)
      [<c053eae4>] (__dev_queue_xmit) from [<c05a5650>] (ip_finish_output2+0x350/0x580)
      [<c05a5650>] (ip_finish_output2) from [<c05a7e24>] (ip_output+0xb4/0x13c)
      [<c05a7e24>] (ip_output) from [<c05a39d0>] (ip_forward+0x474/0x500)
      [<c05a39d0>] (ip_forward) from [<c05a13d8>] (ip_sublist_rcv_finish+0x3c/0x50)
      [<c05a13d8>] (ip_sublist_rcv_finish) from [<c05a19b8>] (ip_sublist_rcv+0x11c/0x188)
      [<c05a19b8>] (ip_sublist_rcv) from [<c05a2494>] (ip_list_rcv+0xf8/0x124)
      [<c05a2494>] (ip_list_rcv) from [<c05403c4>] (__netif_receive_skb_list_core+0x1a0/0x20c)
      [<c05403c4>] (__netif_receive_skb_list_core) from [<c05405c4>] (netif_receive_skb_list_internal+0x194/0x230)
      [<c05405c4>] (netif_receive_skb_list_internal) from [<c0540684>] (gro_normal_list.part.0+0x14/0x28)
      [<c0540684>] (gro_normal_list.part.0) from [<c0541280>] (napi_complete_done+0x16c/0x210)
      [<c0541280>] (napi_complete_done) from [<bf14c1c0>] (r8152_poll+0x684/0x708 [r8152])
      [<bf14c1c0>] (r8152_poll [r8152]) from [<c0541424>] (net_rx_action+0x100/0x328)
      [<c0541424>] (net_rx_action) from [<c01012ec>] (__do_softirq+0xec/0x274)
      [<c01012ec>] (__do_softirq) from [<c012d6d4>] (irq_exit+0xcc/0xd0)
      [<c012d6d4>] (irq_exit) from [<c0160960>] (__handle_domain_irq+0x58/0xa4)
      [<c0160960>] (__handle_domain_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x90)
      Exception stack(0xc0d01ef0 to 0xc0d01f38)
      1ee0:                                     00000000 0000003d 0c31f383 c0d0fa00
      1f00: c0d2eb80 00000000 c0d2e630 4dad8c49 4da967b0 0000003d 0000003d 00000000
      1f20: fffffff5 c0d01f40 c04e0f88 c04e0f8c 30070013 ffffffff
      [<c0100b0c>] (__irq_svc) from [<c04e0f8c>] (cpuidle_enter_state+0x7c/0x378)
      [<c04e0f8c>] (cpuidle_enter_state) from [<c04e12c4>] (cpuidle_enter+0x28/0x38)
      [<c04e12c4>] (cpuidle_enter) from [<c014f710>] (do_idle+0x194/0x214)
      [<c014f710>] (do_idle) from [<c014fa50>] (cpu_startup_entry+0xc/0x14)
      [<c014fa50>] (cpu_startup_entry) from [<c0a00dc8>] (start_kernel+0x46c/0x4a0)
      Code: e580c054 8a000002 e1a00002 e8bd8070 (e7f001f2)
      ---[ end trace 146c8a334115490c ]---
      
      The solution was to force nonlinear buffers to be cloned.  This was previously
      reported by Klaus Doth (https://www.spinics.net/lists/netdev/msg556937.html)
      but never formally submitted as a patch.
      
      This is the third revision, hopefully the formatting is correct this time!
      Suggested-by: default avatarKlaus Doth <krnl@doth.eu>
      Fixes: 653e92a9 ("net: macb: add support for padding and fcs computation")
      Signed-off-by: default avatarMark Deneen <mdeneen@saucontech.com>
      Link: https://lore.kernel.org/r/20201030155814.622831-1-mdeneen@saucontech.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      403dc167
  4. 31 Oct, 2020 5 commits
    • Jakub Kicinski's avatar
      Merge branch 'ipv6-reply-icmp-error-if-fragment-doesn-t-contain-all-headers' · 72a41f95
      Jakub Kicinski authored
      Hangbin Liu says:
      
      ====================
      IPv6: reply ICMP error if fragment doesn't contain all headers
      
      When our Engineer run latest IPv6 Core Conformance test, test v6LC.1.3.6:
      First Fragment Doesn’t Contain All Headers[1] failed. The test purpose is to
      verify that the node (Linux for example) should properly process IPv6 packets
      that don’t include all the headers through the Upper-Layer header.
      
      Based on RFC 8200, Section 4.5 Fragment Header
      
        -  If the first fragment does not include all headers through an
           Upper-Layer header, then that fragment should be discarded and
           an ICMP Parameter Problem, Code 3, message should be sent to
           the source of the fragment, with the Pointer field set to zero.
      
      The first patch add a definition for ICMPv6 Parameter Problem, code 3.
      The second patch add a check for the 1st fragment packet to make sure
      Upper-Layer header exist.
      
      [1] Page 68, v6LC.1.3.6: First Fragment Doesn’t Contain All Headers part A, B,
      C and D at https://ipv6ready.org/docs/Core_Conformance_5_0_0.pdf
      [2] My reproducer:
      
      import sys, os
      from scapy.all import *
      
      def send_frag_dst_opt(src_ip6, dst_ip6):
          ip6 = IPv6(src = src_ip6, dst = dst_ip6, nh = 44)
      
          frag_1 = IPv6ExtHdrFragment(nh = 60, m = 1)
          dst_opt = IPv6ExtHdrDestOpt(nh = 58)
      
          frag_2 = IPv6ExtHdrFragment(nh = 58, offset = 4, m = 1)
          icmp_echo = ICMPv6EchoRequest(seq = 1)
      
          pkt_1 = ip6/frag_1/dst_opt
          pkt_2 = ip6/frag_2/icmp_echo
      
          send(pkt_1)
          send(pkt_2)
      
      def send_frag_route_opt(src_ip6, dst_ip6):
          ip6 = IPv6(src = src_ip6, dst = dst_ip6, nh = 44)
      
          frag_1 = IPv6ExtHdrFragment(nh = 43, m = 1)
          route_opt = IPv6ExtHdrRouting(nh = 58)
      
          frag_2 = IPv6ExtHdrFragment(nh = 58, offset = 4, m = 1)
          icmp_echo = ICMPv6EchoRequest(seq = 2)
      
          pkt_1 = ip6/frag_1/route_opt
          pkt_2 = ip6/frag_2/icmp_echo
      
          send(pkt_1)
          send(pkt_2)
      
      if __name__ == '__main__':
          src = sys.argv[1]
          dst = sys.argv[2]
          conf.iface = sys.argv[3]
          send_frag_dst_opt(src, dst)
          send_frag_route_opt(src, dst)
      ====================
      
      Link: https://lore.kernel.org/r/20201027123313.3717941-1-liuhangbin@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      72a41f95
    • Hangbin Liu's avatar
      IPv6: reply ICMP error if the first fragment don't include all headers · 2efdaaaf
      Hangbin Liu authored
      Based on RFC 8200, Section 4.5 Fragment Header:
      
        -  If the first fragment does not include all headers through an
           Upper-Layer header, then that fragment should be discarded and
           an ICMP Parameter Problem, Code 3, message should be sent to
           the source of the fragment, with the Pointer field set to zero.
      
      Checking each packet header in IPv6 fast path will have performance impact,
      so I put the checking in ipv6_frag_rcv().
      
      As the packet may be any kind of L4 protocol, I only checked some common
      protocols' header length and handle others by (offset + 1) > skb->len.
      Also use !(frag_off & htons(IP6_OFFSET)) to catch atomic fragments
      (fragmented packet with only one fragment).
      
      When send ICMP error message, if the 1st truncated fragment is ICMP message,
      icmp6_send() will break as is_ineligible() return true. So I added a check
      in is_ineligible() to let fragment packet with nexthdr ICMP but no ICMP header
      return false.
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2efdaaaf
    • Hangbin Liu's avatar
      ICMPv6: Add ICMPv6 Parameter Problem, code 3 definition · b59e286b
      Hangbin Liu authored
      Based on RFC7112, Section 6:
      
         IANA has added the following "Type 4 - Parameter Problem" message to
         the "Internet Control Message Protocol version 6 (ICMPv6) Parameters"
         registry:
      
            CODE     NAME/DESCRIPTION
             3       IPv6 First Fragment has incomplete IPv6 Header Chain
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b59e286b
    • Colin Ian King's avatar
      net: atm: fix update of position index in lec_seq_next · 2f71e006
      Colin Ian King authored
      The position index in leq_seq_next is not updated when the next
      entry is fetched an no more entries are available. This causes
      seq_file to report the following error:
      
      "seq_file: buggy .next function lec_seq_next [lec] did not update
       position index"
      
      Fix this by always updating the position index.
      
      [ Note: this is an ancient 2002 bug, the sha is from the
        tglx/history repo ]
      
      Fixes 4aea2cbf ("[ATM]: Move lan seq_file ops to lec.c [1/3]")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Link: https://lore.kernel.org/r/20201027114925.21843-1-colin.king@canonical.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2f71e006
    • Stefano Brivio's avatar
      netfilter: ipset: Update byte and packet counters regardless of whether they match · 7d10e62c
      Stefano Brivio authored
      In ip_set_match_extensions(), for sets with counters, we take care of
      updating counters themselves by calling ip_set_update_counter(), and of
      checking if the given comparison and values match, by calling
      ip_set_match_counter() if needed.
      
      However, if a given comparison on counters doesn't match the configured
      values, that doesn't mean the set entry itself isn't matching.
      
      This fix restores the behaviour we had before commit 4750005a
      ("netfilter: ipset: Fix "don't update counters" mode when counters used
      at the matching"), without reintroducing the issue fixed there: back
      then, mtype_data_match() first updated counters in any case, and then
      took care of matching on counters.
      
      Now, if the IPSET_FLAG_SKIP_COUNTER_UPDATE flag is set,
      ip_set_update_counter() will anyway skip counter updates if desired.
      
      The issue observed is illustrated by this reproducer:
      
        ipset create c hash:ip counters
        ipset add c 192.0.2.1
        iptables -I INPUT -m set --match-set c src --bytes-gt 800 -j DROP
      
      if we now send packets from 192.0.2.1, bytes and packets counters
      for the entry as shown by 'ipset list' are always zero, and, no
      matter how many bytes we send, the rule will never match, because
      counters themselves are not updated.
      Reported-by: default avatarMithil Mhatre <mmhatre@redhat.com>
      Fixes: 4750005a ("netfilter: ipset: Fix "don't update counters" mode when counters used at the matching")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@netfilter.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      7d10e62c
  5. 30 Oct, 2020 2 commits
    • Marek Szyprowski's avatar
      net: stmmac: Fix channel lock initialization · 2b94f526
      Marek Szyprowski authored
      Commit 0366f7e0 ("net: stmmac: add ethtool support for get/set
      channels") refactored channel initialization, but during that operation,
      the spinlock initialization got lost. Fix this. This fixes the following
      lockdep warning:
      
      meson8b-dwmac ff3f0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      CPU: 1 PID: 331 Comm: kworker/1:2H Not tainted 5.9.0-rc3+ #1858
      Hardware name: Hardkernel ODROID-N2 (DT)
      Workqueue: kblockd blk_mq_run_work_fn
      Call trace:
       dump_backtrace+0x0/0x1d0
       show_stack+0x14/0x20
       dump_stack+0xe8/0x154
       register_lock_class+0x58c/0x590
       __lock_acquire+0x7c/0x1790
       lock_acquire+0xf4/0x440
       _raw_spin_lock_irqsave+0x80/0xb0
       stmmac_tx_timer+0x4c/0xb0 [stmmac]
       call_timer_fn+0xc4/0x3e8
       run_timer_softirq+0x2b8/0x6c0
       efi_header_end+0x114/0x5f8
       irq_exit+0x104/0x110
       __handle_domain_irq+0x60/0xb8
       gic_handle_irq+0x58/0xb0
       el1_irq+0xbc/0x180
       _raw_spin_unlock_irqrestore+0x48/0x90
       mmc_blk_rw_wait+0x70/0x160
       mmc_blk_mq_issue_rq+0x510/0x830
       mmc_mq_queue_rq+0x13c/0x278
       blk_mq_dispatch_rq_list+0x2a0/0x698
       __blk_mq_do_dispatch_sched+0x254/0x288
       __blk_mq_sched_dispatch_requests+0x190/0x1d8
       blk_mq_sched_dispatch_requests+0x34/0x70
       __blk_mq_run_hw_queue+0xcc/0x148
       blk_mq_run_work_fn+0x20/0x28
       process_one_work+0x2a8/0x718
       worker_thread+0x48/0x460
       kthread+0x134/0x160
       ret_from_fork+0x10/0x1c
      
      Fixes: 0366f7e0 ("net: stmmac: add ethtool support for get/set channels")
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Link: https://lore.kernel.org/r/20201029185011.4749-1-m.szyprowski@samsung.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2b94f526
    • Wong Vee Khee's avatar
      stmmac: intel: Fix kernel panic on pci probe · 785ff20b
      Wong Vee Khee authored
      The commit "stmmac: intel: Adding ref clock 1us tic for LPI cntr"
      introduced a regression which leads to the kernel panic duing loading
      of the dwmac_intel module.
      
      Move the code block after pci resources is obtained.
      
      Fixes: b4c5f83a ("stmmac: intel: Adding ref clock 1us tic for LPI cntr")
      Cc: Voon Weifeng <weifeng.voon@intel.com>
      Signed-off-by: default avatarWong Vee Khee <vee.khee.wong@intel.com>
      Link: https://lore.kernel.org/r/20201029093228.1741-1-vee.khee.wong@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      785ff20b