1. 15 Jun, 2021 5 commits
    • Aleksander Jan Bajkowski's avatar
      lantiq: net: fix duplicated skb in rx descriptor ring · 7ea6cd16
      Aleksander Jan Bajkowski authored
      The previous commit didn't fix the bug properly. By mistake, it replaces
      the pointer of the next skb in the descriptor ring instead of the current
      one. As a result, the two descriptors are assigned the same SKB. The error
      is seen during the iperf test when skb_put tries to insert a second packet
      and exceeds the available buffer.
      
      Fixes: c7718ee9 ("net: lantiq: fix memory corruption in RX ring ")
      Signed-off-by: default avatarAleksander Jan Bajkowski <olek2@wp.pl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7ea6cd16
    • Kristian Evensen's avatar
      qmi_wwan: Do not call netif_rx from rx_fixup · 057d4933
      Kristian Evensen authored
      When the QMI_WWAN_FLAG_PASS_THROUGH is set, netif_rx() is called from
      qmi_wwan_rx_fixup(). When the call to netif_rx() is successful (which is
      most of the time), usbnet_skb_return() is called (from rx_process()).
      usbnet_skb_return() will then call netif_rx() a second time for the same
      skb.
      
      Simplify the code and avoid the redundant netif_rx() call by changing
      qmi_wwan_rx_fixup() to always return 1 when QMI_WWAN_FLAG_PASS_THROUGH
      is set. We then leave it up to the existing infrastructure to call
      netif_rx().
      Suggested-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      057d4933
    • Maciej Żenczykowski's avatar
      net: cdc_ncm: switch to eth%d interface naming · c1a3d406
      Maciej Żenczykowski authored
      This is meant to make the host side cdc_ncm interface consistently
      named just like the older CDC protocols: cdc_ether & cdc_ecm
      (and even rndis_host), which all use 'FLAG_ETHER | FLAG_POINTTOPOINT'.
      
      include/linux/usb/usbnet.h:
        #define FLAG_ETHER	0x0020		/* maybe use "eth%d" names */
        #define FLAG_WLAN	0x0080		/* use "wlan%d" names */
        #define FLAG_WWAN	0x0400		/* use "wwan%d" names */
        #define FLAG_POINTTOPOINT 0x1000	/* possibly use "usb%d" names */
      
      drivers/net/usb/usbnet.c @ line 1711:
        strcpy (net->name, "usb%d");
        ...
        // heuristic:  "usb%d" for links we know are two-host,
        // else "eth%d" when there's reasonable doubt.  userspace
        // can rename the link if it knows better.
        if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
            ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
             (net->dev_addr [0] & 0x02) == 0))
                strcpy (net->name, "eth%d");
        /* WLAN devices should always be named "wlan%d" */
        if ((dev->driver_info->flags & FLAG_WLAN) != 0)
                strcpy(net->name, "wlan%d");
        /* WWAN devices should always be named "wwan%d" */
        if ((dev->driver_info->flags & FLAG_WWAN) != 0)
                strcpy(net->name, "wwan%d");
      
      So by using ETHER | POINTTOPOINT the interface naming is
      either usb%d or eth%d based on the global uniqueness of the
      mac address of the device.
      
      Without this 2.5gbps ethernet dongles which all seem to use the cdc_ncm
      driver end up being called usb%d instead of eth%d even though they're
      definitely not two-host.  (All 1gbps & 5gbps ethernet usb dongles I've
      tested don't hit this problem due to use of different drivers, primarily
      r8152 and aqc111)
      
      Fixes tag is based purely on git blame, and is really just here to make
      sure this hits LTS branches newer than v4.5.
      
      Cc: Lorenzo Colitti <lorenzo@google.com>
      Fixes: 4d06dd53 ("cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind")
      Signed-off-by: default avatarMaciej Żenczykowski <maze@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1a3d406
    • Changbin Du's avatar
      net: inline function get_net_ns_by_fd if NET_NS is disabled · e34492de
      Changbin Du authored
      The function get_net_ns_by_fd() could be inlined when NET_NS is not
      enabled.
      Signed-off-by: default avatarChangbin Du <changbin.du@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e34492de
    • 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 15 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