1. 15 Jun, 2021 1 commit
    • Jakub Kicinski's avatar
      ptp: improve max_adj check against unreasonable values · 475b92f9
      Jakub Kicinski authored
      Scaled PPM conversion to PPB may (on 64bit systems) result
      in a value larger than s32 can hold (freq/scaled_ppm is a long).
      This means the kernel will not correctly reject unreasonably
      high ->freq values (e.g. > 4294967295ppb, 281474976645 scaled PPM).
      
      The conversion is equivalent to a division by ~66 (65.536),
      so the value of ppb is always smaller than ppm, but not small
      enough to assume narrowing the type from long -> s32 is okay.
      
      Note that reasonable user space (e.g. ptp4l) will not use such
      high values, anyway, 4289046510ppb ~= 4.3x, so the fix is
      somewhat pedantic.
      
      Fixes: d39a7435 ("ptp: validate the requested frequency adjustment.")
      Fixes: d94ba80e ("ptp: Added a brand new class driver for ptp clocks.")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      475b92f9
  2. 14 Jun, 2021 12 commits
  3. 12 Jun, 2021 1 commit
    • Changbin Du's avatar
      net: make get_net_ns return error if NET_NS is disabled · ea6932d7
      Changbin Du authored
      There is a panic in socket ioctl cmd SIOCGSKNS when NET_NS is not enabled.
      The reason is that nsfs tries to access ns->ops but the proc_ns_operations
      is not implemented in this case.
      
      [7.670023] Unable to handle kernel NULL pointer dereference at virtual address 00000010
      [7.670268] pgd = 32b54000
      [7.670544] [00000010] *pgd=00000000
      [7.671861] Internal error: Oops: 5 [#1] SMP ARM
      [7.672315] Modules linked in:
      [7.672918] CPU: 0 PID: 1 Comm: systemd Not tainted 5.13.0-rc3-00375-g6799d4f2 #16
      [7.673309] Hardware name: Generic DT based system
      [7.673642] PC is at nsfs_evict+0x24/0x30
      [7.674486] LR is at clear_inode+0x20/0x9c
      
      The same to tun SIOCGSKNS command.
      
      To fix this problem, we make get_net_ns() return -EINVAL when NET_NS is
      disabled. Meanwhile move it to right place net/core/net_namespace.c.
      Signed-off-by: default avatarChangbin Du <changbin.du@gmail.com>
      Fixes: c62cce2c ("net: add an ioctl to get a socket network namespace")
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Christian Brauner <christian.brauner@ubuntu.com>
      Suggested-by: default avatarJakub Kicinski <kuba@kernel.org>
      Acked-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ea6932d7
  4. 11 Jun, 2021 7 commits
  5. 10 Jun, 2021 19 commits
    • David S. Miller's avatar
      Merge branch 'mptcp-fixes' · 232e3683
      David S. Miller authored
      Mat Martineau says:
      
      ====================
      mptcp: More v5.13 fixes
      
      Here's another batch of MPTCP fixes for v5.13.
      
      Patch 1 cleans up memory accounting between the MPTCP-level socket and
      the subflows to more reliably transfer forward allocated memory under
      pressure.
      
      Patch 2 wakes up socket readers more reliably.
      
      Patch 3 changes a WARN_ONCE to a pr_debug.
      
      Patch 4 changes the selftests to only use syncookies in test cases where
      they do not cause spurious failures.
      
      Patch 5 modifies socket error reporting to avoid a possible soft lockup.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      232e3683
    • Paolo Abeni's avatar
      mptcp: fix soft lookup in subflow_error_report() · 499ada50
      Paolo Abeni authored
      Maxim reported a soft lookup in subflow_error_report():
      
       watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
       RIP: 0010:native_queued_spin_lock_slowpath
       RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202
       RAX: 0000000000000101 RBX: 0000000000000001 RCX: 0000000000000000
       RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88
       RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4
       R10: ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88
       R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700
       FS:  0000000000000000(0000) GS:ffff91961f400000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 000000c000407000 CR3: 0000000002988000 CR4: 00000000000006f0
       Call Trace:
        <IRQ>
       _raw_spin_lock_bh
       subflow_error_report
       mptcp_subflow_data_available
       __mptcp_move_skbs_from_subflow
       mptcp_data_ready
       tcp_data_queue
       tcp_rcv_established
       tcp_v4_do_rcv
       tcp_v4_rcv
       ip_protocol_deliver_rcu
       ip_local_deliver_finish
       __netif_receive_skb_one_core
       netif_receive_skb
       rtl8139_poll 8139too
       __napi_poll
       net_rx_action
       __do_softirq
       __irq_exit_rcu
       common_interrupt
        </IRQ>
      
      The calling function - mptcp_subflow_data_available() - can be invoked
      from different contexts:
      - plain ssk socket lock
      - ssk socket lock + mptcp_data_lock
      - ssk socket lock + mptcp_data_lock + msk socket lock.
      
      Since subflow_error_report() tries to acquire the mptcp_data_lock, the
      latter two call chains will cause soft lookup.
      
      This change addresses the issue moving the error reporting call to
      outer functions, where the held locks list is known and the we can
      acquire only the needed one.
      Reported-by: default avatarMaxim Galaganov <max@internet.ru>
      Fixes: 15cc1045 ("mptcp: deliver ssk errors to msk")
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/199Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      499ada50
    • Paolo Abeni's avatar
      selftests: mptcp: enable syncookie only in absence of reorders · 2395da0e
      Paolo Abeni authored
      Syncookie validation may fail for OoO packets, causing spurious
      resets and self-tests failures, so let's force syncookie only
      for tests iteration with no OoO.
      
      Fixes: fed61c4b ("selftests: mptcp: make 2nd net namespace use tcp syn cookies unconditionally")
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/198Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2395da0e
    • Paolo Abeni's avatar
      mptcp: do not warn on bad input from the network · 61e71022
      Paolo Abeni authored
      warn_bad_map() produces a kernel WARN on bad input coming
      from the network. Use pr_debug() to avoid spamming the system
      log.
      
      Additionally, when the right bound check fails, warn_bad_map() reports
      the wrong ssn value, let's fix it.
      
      Fixes: 648ef4b8 ("mptcp: Implement MPTCP receive path")
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/107Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61e71022
    • Paolo Abeni's avatar
      mptcp: wake-up readers only for in sequence data · 99d1055c
      Paolo Abeni authored
      Currently we rely on the subflow->data_avail field, which is subject to
      races:
      
      	ssk1
      		skb len = 500 DSS(seq=1, len=1000, off=0)
      		# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
      
      	ssk2
      		skb len = 500 DSS(seq = 501, len=1000)
      		# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
      
      	ssk1
      		skb len = 500 DSS(seq = 1, len=1000, off =500)
      		# still data_avail == MPTCP_SUBFLOW_DATA_AVAIL,
      		# as the skb is covered by a pre-existing map,
      		# which was in-sequence at reception time.
      
      Instead we can explicitly check if some has been received in-sequence,
      propagating the info from __mptcp_move_skbs_from_subflow().
      
      Additionally add the 'ONCE' annotation to the 'data_avail' memory
      access, as msk will read it outside the subflow socket lock.
      
      Fixes: 648ef4b8 ("mptcp: Implement MPTCP receive path")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99d1055c
    • Paolo Abeni's avatar
      mptcp: try harder to borrow memory from subflow under pressure · 72f96132
      Paolo Abeni authored
      If the host is under sever memory pressure, and RX forward
      memory allocation for the msk fails, we try to borrow the
      required memory from the ingress subflow.
      
      The current attempt is a bit flaky: if skb->truesize is less
      than SK_MEM_QUANTUM, the ssk will not release any memory, and
      the next schedule will fail again.
      
      Instead, directly move the required amount of pages from the
      ssk to the msk, if available
      
      Fixes: 9c3f94e1 ("mptcp: add missing memory scheduling in the rx path")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72f96132
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 22488e45
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for net:
      
      1) Fix a crash when stateful expression with its own gc callback
         is used in a set definition.
      
      2) Skip IPv6 packets from any link-local address in IPv6 fib expression.
         Add a selftest for this scenario, from Florian Westphal.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22488e45
    • David S. Miller's avatar
      Merge branch 'tcp-options-oob-fixes' · 0280f429
      David S. Miller authored
      Maxim Mikityanskiy says:
      
      ====================
      Fix out of bounds when parsing TCP options
      
      This series fixes out-of-bounds access in various places in the kernel
      where parsing of TCP options takes place. Fortunately, many more
      occurrences don't have this bug.
      
      v2 changes:
      
      synproxy: Added an early return when length < 0 to avoid calling
      skb_header_pointer with negative length.
      
      sch_cake: Added doff validation to avoid parsing garbage.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0280f429
    • Maxim Mikityanskiy's avatar
      sch_cake: Fix out of bounds when parsing TCP options and header · ba91c49d
      Maxim Mikityanskiy authored
      The TCP option parser in cake qdisc (cake_get_tcpopt and
      cake_tcph_may_drop) could read one byte out of bounds. When the length
      is 1, the execution flow gets into the loop, reads one byte of the
      opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads
      one more byte, which exceeds the length of 1.
      
      This fix is inspired by commit 9609dad2 ("ipv4: tcp_input: fix stack
      out of bounds when parsing TCP options.").
      
      v2 changes:
      
      Added doff validation in cake_get_tcphdr to avoid parsing garbage as TCP
      header. Although it wasn't strictly an out-of-bounds access (memory was
      allocated), garbage values could be read where CAKE expected the TCP
      header if doff was smaller than 5.
      
      Cc: Young Xiao <92siuyang@gmail.com>
      Fixes: 8b713881 ("sch_cake: Add optional ACK filter")
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@nvidia.com>
      Acked-by: default avatarToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba91c49d
    • Maxim Mikityanskiy's avatar
      mptcp: Fix out of bounds when parsing TCP options · 07718be2
      Maxim Mikityanskiy authored
      The TCP option parser in mptcp (mptcp_get_options) could read one byte
      out of bounds. When the length is 1, the execution flow gets into the
      loop, reads one byte of the opcode, and if the opcode is neither
      TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the
      length of 1.
      
      This fix is inspired by commit 9609dad2 ("ipv4: tcp_input: fix stack
      out of bounds when parsing TCP options.").
      
      Cc: Young Xiao <92siuyang@gmail.com>
      Fixes: cec37a6e ("mptcp: Handle MP_CAPABLE options for outgoing connections")
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@nvidia.com>
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07718be2
    • Maxim Mikityanskiy's avatar
      netfilter: synproxy: Fix out of bounds when parsing TCP options · 5fc177ab
      Maxim Mikityanskiy authored
      The TCP option parser in synproxy (synproxy_parse_options) could read
      one byte out of bounds. When the length is 1, the execution flow gets
      into the loop, reads one byte of the opcode, and if the opcode is
      neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds
      the length of 1.
      
      This fix is inspired by commit 9609dad2 ("ipv4: tcp_input: fix stack
      out of bounds when parsing TCP options.").
      
      v2 changes:
      
      Added an early return when length < 0 to avoid calling
      skb_header_pointer with negative length.
      
      Cc: Young Xiao <92siuyang@gmail.com>
      Fixes: 48b1de4c ("netfilter: add SYNPROXY core/target")
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@nvidia.com>
      Reviewed-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fc177ab
    • Eric Dumazet's avatar
      net/packet: annotate data race in packet_sendmsg() · d1b5bee4
      Eric Dumazet authored
      There is a known race in packet_sendmsg(), addressed
      in commit 32d3182c ("net/packet: fix race in tpacket_snd()")
      
      Now we have data_race(), we can use it to avoid a future KCSAN warning,
      as syzbot loves stressing af_packet sockets :)
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1b5bee4
    • Eric Dumazet's avatar
      inet: annotate date races around sk->sk_txhash · b71eaed8
      Eric Dumazet authored
      UDP sendmsg() path can be lockless, it is possible for another
      thread to re-connect an change sk->sk_txhash under us.
      
      There is no serious impact, but we can use READ_ONCE()/WRITE_ONCE()
      pair to document the race.
      
      BUG: KCSAN: data-race in __ip4_datagram_connect / skb_set_owner_w
      
      write to 0xffff88813397920c of 4 bytes by task 30997 on cpu 1:
       sk_set_txhash include/net/sock.h:1937 [inline]
       __ip4_datagram_connect+0x69e/0x710 net/ipv4/datagram.c:75
       __ip6_datagram_connect+0x551/0x840 net/ipv6/datagram.c:189
       ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272
       inet_dgram_connect+0xfd/0x180 net/ipv4/af_inet.c:580
       __sys_connect_file net/socket.c:1837 [inline]
       __sys_connect+0x245/0x280 net/socket.c:1854
       __do_sys_connect net/socket.c:1864 [inline]
       __se_sys_connect net/socket.c:1861 [inline]
       __x64_sys_connect+0x3d/0x50 net/socket.c:1861
       do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      read to 0xffff88813397920c of 4 bytes by task 31039 on cpu 0:
       skb_set_hash_from_sk include/net/sock.h:2211 [inline]
       skb_set_owner_w+0x118/0x220 net/core/sock.c:2101
       sock_alloc_send_pskb+0x452/0x4e0 net/core/sock.c:2359
       sock_alloc_send_skb+0x2d/0x40 net/core/sock.c:2373
       __ip6_append_data+0x1743/0x21a0 net/ipv6/ip6_output.c:1621
       ip6_make_skb+0x258/0x420 net/ipv6/ip6_output.c:1983
       udpv6_sendmsg+0x160a/0x16b0 net/ipv6/udp.c:1527
       inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:642
       sock_sendmsg_nosec net/socket.c:654 [inline]
       sock_sendmsg net/socket.c:674 [inline]
       ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350
       ___sys_sendmsg net/socket.c:2404 [inline]
       __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490
       __do_sys_sendmmsg net/socket.c:2519 [inline]
       __se_sys_sendmmsg net/socket.c:2516 [inline]
       __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516
       do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      value changed: 0xbca3c43d -> 0xfdb309e0
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 31039 Comm: syz-executor.2 Not tainted 5.13.0-rc3-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      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>
      b71eaed8
    • Eric Dumazet's avatar
      net: annotate data race in sock_error() · f13ef100
      Eric Dumazet authored
      sock_error() is known to be racy. The code avoids
      an atomic operation is sk_err is zero, and this field
      could be changed under us, this is fine.
      
      Sysbot reported:
      
      BUG: KCSAN: data-race in sock_alloc_send_pskb / unix_release_sock
      
      write to 0xffff888131855630 of 4 bytes by task 9365 on cpu 1:
       unix_release_sock+0x2e9/0x6e0 net/unix/af_unix.c:550
       unix_release+0x2f/0x50 net/unix/af_unix.c:859
       __sock_release net/socket.c:599 [inline]
       sock_close+0x6c/0x150 net/socket.c:1258
       __fput+0x25b/0x4e0 fs/file_table.c:280
       ____fput+0x11/0x20 fs/file_table.c:313
       task_work_run+0xae/0x130 kernel/task_work.c:164
       tracehook_notify_resume include/linux/tracehook.h:189 [inline]
       exit_to_user_mode_loop kernel/entry/common.c:174 [inline]
       exit_to_user_mode_prepare+0x156/0x190 kernel/entry/common.c:208
       __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
       syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:301
       do_syscall_64+0x56/0x90 arch/x86/entry/common.c:57
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      read to 0xffff888131855630 of 4 bytes by task 9385 on cpu 0:
       sock_error include/net/sock.h:2269 [inline]
       sock_alloc_send_pskb+0xe4/0x4e0 net/core/sock.c:2336
       unix_dgram_sendmsg+0x478/0x1610 net/unix/af_unix.c:1671
       unix_seqpacket_sendmsg+0xc2/0x100 net/unix/af_unix.c:2055
       sock_sendmsg_nosec net/socket.c:654 [inline]
       sock_sendmsg net/socket.c:674 [inline]
       ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350
       __sys_sendmsg_sock+0x25/0x30 net/socket.c:2416
       io_sendmsg fs/io_uring.c:4367 [inline]
       io_issue_sqe+0x231a/0x6750 fs/io_uring.c:6135
       __io_queue_sqe+0xe9/0x360 fs/io_uring.c:6414
       __io_req_task_submit fs/io_uring.c:2039 [inline]
       io_async_task_func+0x312/0x590 fs/io_uring.c:5074
       __tctx_task_work fs/io_uring.c:1910 [inline]
       tctx_task_work+0x1d4/0x3d0 fs/io_uring.c:1924
       task_work_run+0xae/0x130 kernel/task_work.c:164
       tracehook_notify_signal include/linux/tracehook.h:212 [inline]
       handle_signal_work kernel/entry/common.c:145 [inline]
       exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
       exit_to_user_mode_prepare+0xf8/0x190 kernel/entry/common.c:208
       __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
       syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:301
       do_syscall_64+0x56/0x90 arch/x86/entry/common.c:57
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      value changed: 0x00000000 -> 0x00000068
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 9385 Comm: syz-executor.3 Not tainted 5.13.0-rc4-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      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>
      f13ef100
    • David S. Miller's avatar
      Merge branch 'bridge-egress-fixes' · 172947ac
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      net: bridge: vlan tunnel egress path fixes
      
      These two fixes take care of tunnel_dst problems in the vlan tunnel egress
      path. Patch 01 fixes a null ptr deref due to the lockless use of tunnel_dst
      pointer without checking it first, and patch 02 fixes a use-after-free
      issue due to wrong dst refcounting (dst_clone() -> dst_hold_safe()).
      
      Both fix the same commit and should be queued for stable backports:
      Fixes: 11538d03 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
      
      v2: no changes, added stable list to CC
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      172947ac
    • Nikolay Aleksandrov's avatar
      net: bridge: fix vlan tunnel dst refcnt when egressing · cfc579f9
      Nikolay Aleksandrov authored
      The egress tunnel code uses dst_clone() and directly sets the result
      which is wrong because the entry might have 0 refcnt or be already deleted,
      causing number of problems. It also triggers the WARN_ON() in dst_hold()[1]
      when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and
      checking if a reference was actually taken before setting the dst.
      
      [1] dmesg WARN_ON log and following refcnt errors
       WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
       Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net
       CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G        W         5.13.0-rc3+ #360
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
       RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
       Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49
       RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0
       RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001
       R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000
       R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401
       FS:  0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0
       Call Trace:
        br_handle_vlan+0xbc/0xca [bridge]
        __br_forward+0x23/0x164 [bridge]
        deliver_clone+0x41/0x48 [bridge]
        br_handle_frame_finish+0x36f/0x3aa [bridge]
        ? skb_dst+0x2e/0x38 [bridge]
        ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge]
        ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
        br_handle_frame+0x2c3/0x377 [bridge]
        ? __skb_pull+0x33/0x51
        ? vlan_do_receive+0x4f/0x36a
        ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
        __netif_receive_skb_core+0x539/0x7c6
        ? __list_del_entry_valid+0x16e/0x1c2
        __netif_receive_skb_list_core+0x6d/0xd6
        netif_receive_skb_list_internal+0x1d9/0x1fa
        gro_normal_list+0x22/0x3e
        dev_gro_receive+0x55b/0x600
        ? detach_buf_split+0x58/0x140
        napi_gro_receive+0x94/0x12e
        virtnet_poll+0x15d/0x315 [virtio_net]
        __napi_poll+0x2c/0x1c9
        net_rx_action+0xe6/0x1fb
        __do_softirq+0x115/0x2d8
        run_ksoftirqd+0x18/0x20
        smpboot_thread_fn+0x183/0x19c
        ? smpboot_unregister_percpu_thread+0x66/0x66
        kthread+0x10a/0x10f
        ? kthread_mod_delayed_work+0xb6/0xb6
        ret_from_fork+0x22/0x30
       ---[ end trace 49f61b07f775fd2b ]---
       dst_release: dst:00000000c02d677a refcnt:-1
       dst_release underflow
      
      Cc: stable@vger.kernel.org
      Fixes: 11538d03 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfc579f9
    • Nikolay Aleksandrov's avatar
      net: bridge: fix vlan tunnel dst null pointer dereference · 58e20717
      Nikolay Aleksandrov authored
      This patch fixes a tunnel_dst null pointer dereference due to lockless
      access in the tunnel egress path. When deleting a vlan tunnel the
      tunnel_dst pointer is set to NULL without waiting a grace period (i.e.
      while it's still usable) and packets egressing are dereferencing it
      without checking. Use READ/WRITE_ONCE to annotate the lockless use of
      tunnel_id, use RCU for accessing tunnel_dst and make sure it is read
      only once and checked in the egress path. The dst is already properly RCU
      protected so we don't need to do anything fancy than to make sure
      tunnel_id and tunnel_dst are read only once and checked in the egress path.
      
      Cc: stable@vger.kernel.org
      Fixes: 11538d03 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58e20717
    • Zheng Yongjun's avatar
      ping: Check return value of function 'ping_queue_rcv_skb' · 9d44fa3e
      Zheng Yongjun authored
      Function 'ping_queue_rcv_skb' not always return success, which will
      also return fail. If not check the wrong return value of it, lead to function
      `ping_rcv` return success.
      Signed-off-by: default avatarZheng Yongjun <zhengyongjun3@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d44fa3e
    • Willem de Bruijn's avatar
      skbuff: fix incorrect msg_zerocopy copy notifications · 3bdd5ee0
      Willem de Bruijn authored
      msg_zerocopy signals if a send operation required copying with a flag
      in serr->ee.ee_code.
      
      This field can be incorrect as of the below commit, as a result of
      both structs uarg and serr pointing into the same skb->cb[].
      
      uarg->zerocopy must be read before skb->cb[] is reinitialized to hold
      serr. Similar to other fields len, hi and lo, use a local variable to
      temporarily hold the value.
      
      This was not a problem before, when the value was passed as a function
      argument.
      
      Fixes: 75518851 ("skbuff: Push status and refcounts into sock_zerocopy_callback")
      Reported-by: default avatarTalal Ahmad <talalahmad@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bdd5ee0