1. 29 Nov, 2022 9 commits
    • YueHaibing's avatar
      net: hsr: Fix potential use-after-free · 7e177d32
      YueHaibing authored
      The skb is delivered to netif_rx() which may free it, after calling this,
      dereferencing skb may trigger use-after-free.
      
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Link: https://lore.kernel.org/r/20221125075724.27912-1-yuehaibing@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7e177d32
    • Xin Long's avatar
      tipc: re-fetch skb cb after tipc_msg_validate · 3067bc61
      Xin Long authored
      As the call trace shows, the original skb was freed in tipc_msg_validate(),
      and dereferencing the old skb cb would cause an use-after-free crash.
      
        BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
        Call Trace:
         <IRQ>
         tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
         tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
         tipc_rcv+0x744/0x1150 [tipc]
        ...
        Allocated by task 47078:
         kmem_cache_alloc_node+0x158/0x4d0
         __alloc_skb+0x1c1/0x270
         tipc_buf_acquire+0x1e/0xe0 [tipc]
         tipc_msg_create+0x33/0x1c0 [tipc]
         tipc_link_build_proto_msg+0x38a/0x2100 [tipc]
         tipc_link_timeout+0x8b8/0xef0 [tipc]
         tipc_node_timeout+0x2a1/0x960 [tipc]
         call_timer_fn+0x2d/0x1c0
        ...
        Freed by task 47078:
         tipc_msg_validate+0x7b/0x440 [tipc]
         tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]
         tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
         tipc_rcv+0x744/0x1150 [tipc]
      
      This patch fixes it by re-fetching the skb cb from the new allocated skb
      after calling tipc_msg_validate().
      
      Fixes: fc1b6d6d ("tipc: introduce TIPC encryption & authentication")
      Reported-by: default avatarShuang Li <shuali@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Link: https://lore.kernel.org/r/1b1cdba762915325bd8ef9a98d0276eb673df2a5.1669398403.git.lucien.xin@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3067bc61
    • Jakub Kicinski's avatar
      Merge branch 'mptcp-more-fixes-for-6-1' · ce2e1c6d
      Jakub Kicinski authored
      Matthieu Baerts says:
      
      ====================
      mptcp: More fixes for 6.1
      
      Patch 1 makes sure data received after a close will still be processed
      and acked as exepected. This is a regression for a commit introduced
      in v5.11.
      
      Patch 2 fixes a kernel deadlock found when working on validating TFO
      with a listener MPTCP socket. This is not directly linked to TFO but
      it is easier to reproduce the issue with it. This fixes a bug introduced
      by a commit from v6.0.
      ====================
      
      Link: https://lore.kernel.org/r/20221128154239.1999234-1-matthieu.baerts@tessares.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ce2e1c6d
    • Paolo Abeni's avatar
      mptcp: fix sleep in atomic at close time · b4f16665
      Paolo Abeni authored
      Matt reported a splat at msk close time:
      
          BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877
          in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill
          preempt_count: 201, expected: 0
          RCU nest depth: 0, expected: 0
          4 locks held by packetdrill/155:
          #0: ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650)
          #1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973)
          #2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363)
          #3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820)
          Preemption disabled at:
          0x0
          CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
          Call Trace:
          <TASK>
          dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
          __might_resched.cold (kernel/sched/core.c:9891)
          __mptcp_destroy_sock (include/linux/kernel.h:110)
          __mptcp_close (net/mptcp/protocol.c:2959)
          mptcp_subflow_queue_clean (include/net/sock.h:1777)
          __mptcp_close_ssk (net/mptcp/protocol.c:2363)
          mptcp_destroy_common (net/mptcp/protocol.c:3170)
          mptcp_destroy (include/net/sock.h:1495)
          __mptcp_destroy_sock (net/mptcp/protocol.c:2886)
          __mptcp_close (net/mptcp/protocol.c:2959)
          mptcp_close (net/mptcp/protocol.c:2974)
          inet_release (net/ipv4/af_inet.c:432)
          __sock_release (net/socket.c:651)
          sock_close (net/socket.c:1367)
          __fput (fs/file_table.c:320)
          task_work_run (kernel/task_work.c:181 (discriminator 1))
          exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49)
          syscall_exit_to_user_mode (kernel/entry/common.c:130)
          do_syscall_64 (arch/x86/entry/common.c:87)
          entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
      
      We can't call mptcp_close under the 'fast' socket lock variant, replace
      it with a sock_lock_nested() as the relevant code is already under the
      listening msk socket lock protection.
      Reported-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/316
      Fixes: 30e51b92 ("mptcp: fix unreleased socket in accept queue")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b4f16665
    • Menglong Dong's avatar
      mptcp: don't orphan ssk in mptcp_close() · fe948001
      Menglong Dong authored
      All of the subflows of a msk will be orphaned in mptcp_close(), which
      means the subflows are in DEAD state. After then, DATA_FIN will be sent,
      and the other side will response with a DATA_ACK for this DATA_FIN.
      
      However, if the other side still has pending data, the data that received
      on these subflows will not be passed to the msk, as they are DEAD and
      subflow_data_ready() will not be called in tcp_data_ready(). Therefore,
      these data can't be acked, and they will be retransmitted again and again,
      until timeout.
      
      Fix this by setting ssk->sk_socket and ssk->sk_wq to 'NULL', instead of
      orphaning the subflows in __mptcp_close(), as Paolo suggested.
      
      Fixes: e16163b6 ("mptcp: refactor shutdown and close")
      Reviewed-by: default avatarBiao Jiang <benbjiang@tencent.com>
      Reviewed-by: default avatarMengen Sun <mengensun@tencent.com>
      Signed-off-by: default avatarMenglong Dong <imagedong@tencent.com>
      Reviewed-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fe948001
    • Jerry Ray's avatar
      dsa: lan9303: Correct stat name · 39f59bca
      Jerry Ray authored
      This patch changes the reported ethtool statistics for the lan9303
      family of parts covered by this driver.
      
      The TxUnderRun statistic label is renamed to RxShort to accurately
      reflect what stat the device is reporting.  I did not reorder the
      statistics as that might cause problems with existing user code that
      are expecting the stats at a certain offset.
      
      Fixes: a1292595 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303")
      Signed-off-by: default avatarJerry Ray <jerry.ray@microchip.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20221128193559.6572-1-jerry.ray@microchip.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      39f59bca
    • Jakub Kicinski's avatar
      Merge tag 'wireless-2022-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless · 02f248ea
      Jakub Kicinski authored
      Kalle Valo says:
      
      ====================
      wireless fixes for v6.1
      
      Third, and hopefully final, set of fixes for v6.1. We are marking the
      rsi driver as orphan, have some Information Element parsing fixes to
      wilc1000 driver and three small fixes to the stack.
      
      * tag 'wireless-2022-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
        wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration
        wifi: cfg80211: don't allow multi-BSSID in S1G
        wifi: cfg80211: fix buffer overflow in elem comparison
        wifi: wilc1000: validate number of channels
        wifi: wilc1000: validate length of IEEE80211_P2P_ATTR_CHANNEL_LIST attribute
        wifi: wilc1000: validate length of IEEE80211_P2P_ATTR_OPER_CHANNEL attribute
        wifi: wilc1000: validate pairwise and authentication suite offsets
        MAINTAINERS: mark rsi wifi driver as orphan
      ====================
      
      Link: https://lore.kernel.org/r/20221128113513.6F459C433C1@smtp.kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      02f248ea
    • Jakub Kicinski's avatar
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 4f4a5de1
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      bpf 2022-11-25
      
      We've added 10 non-merge commits during the last 8 day(s) which contain
      a total of 7 files changed, 48 insertions(+), 30 deletions(-).
      
      The main changes are:
      
      1) Several libbpf ringbuf fixes related to probing for its availability,
         size overflows when mmaping a 2G ringbuf and rejection of invalid
         reservationsizes, from Hou Tao.
      
      2) Fix a buggy return pointer in libbpf for attach_raw_tp function,
         from Jiri Olsa.
      
      3) Fix a local storage BPF map bug where the value's spin lock field
         can get initialized incorrectly, from Xu Kuohai.
      
      4) Two follow-up fixes in kprobe_multi BPF selftests for BPF CI,
         from Jiri Olsa.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
        selftests/bpf: Make test_bench_attach serial
        selftests/bpf: Filter out default_idle from kprobe_multi bench
        bpf: Set and check spin lock value in sk_storage_map_test
        bpf: Do not copy spin lock field from user in bpf_selem_alloc
        libbpf: Check the validity of size in user_ring_buffer__reserve()
        libbpf: Handle size overflow for user ringbuf mmap
        libbpf: Handle size overflow for ringbuf mmap
        libbpf: Use page size as max_entries when probing ring buffer map
        bpf, perf: Use subprog name when reporting subprog ksymbol
        libbpf: Use correct return pointer in attach_raw_tp
      ====================
      
      Link: https://lore.kernel.org/r/20221125001034.29473-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4f4a5de1
    • Ido Schimmel's avatar
      ipv4: Fix route deletion when nexthop info is not specified · d5082d38
      Ido Schimmel authored
      When the kernel receives a route deletion request from user space it
      tries to delete a route that matches the route attributes specified in
      the request.
      
      If only prefix information is specified in the request, the kernel
      should delete the first matching FIB alias regardless of its associated
      FIB info. However, an error is currently returned when the FIB info is
      backed by a nexthop object:
      
       # ip nexthop add id 1 via 192.0.2.2 dev dummy10
       # ip route add 198.51.100.0/24 nhid 1
       # ip route del 198.51.100.0/24
       RTNETLINK answers: No such process
      
      Fix by matching on such a FIB info when legacy nexthop attributes are
      not specified in the request. An earlier check already covers the case
      where a nexthop ID is specified in the request.
      
      Add tests that cover these flows. Before the fix:
      
       # ./fib_nexthops.sh -t ipv4_fcnal
       ...
       TEST: Delete route when not specifying nexthop attributes           [FAIL]
      
       Tests passed:  11
       Tests failed:   1
      
      After the fix:
      
       # ./fib_nexthops.sh -t ipv4_fcnal
       ...
       TEST: Delete route when not specifying nexthop attributes           [ OK ]
      
       Tests passed:  12
       Tests failed:   0
      
      No regressions in other tests:
      
       # ./fib_nexthops.sh
       ...
       Tests passed: 228
       Tests failed:   0
      
       # ./fib_tests.sh
       ...
       Tests passed: 186
       Tests failed:   0
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarJonas Gorski <jonas.gorski@gmail.com>
      Tested-by: default avatarJonas Gorski <jonas.gorski@gmail.com>
      Fixes: 493ced1a ("ipv4: Allow routes to use nexthop objects")
      Fixes: 6bf92d70 ("net: ipv4: fix route with nexthop object delete warning")
      Fixes: 61b91eb3 ("ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Link: https://lore.kernel.org/r/20221124210932.2470010-1-idosch@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d5082d38
  2. 28 Nov, 2022 12 commits
  3. 27 Nov, 2022 1 commit
    • Yang Yingliang's avatar
      net: phy: fix null-ptr-deref while probe() failed · 369eb2c9
      Yang Yingliang authored
      I got a null-ptr-deref report as following when doing fault injection test:
      
      BUG: kernel NULL pointer dereference, address: 0000000000000058
      Oops: 0000 [#1] PREEMPT SMP KASAN PTI
      CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
      RIP: 0010:klist_put+0x2d/0xd0
      Call Trace:
       <TASK>
       klist_remove+0xf1/0x1c0
       device_release_driver_internal+0x23e/0x2d0
       bus_remove_device+0x1bd/0x240
       device_del+0x357/0x770
       phy_device_remove+0x11/0x30
       mdiobus_unregister+0xa5/0x140
       release_nodes+0x6a/0xa0
       devres_release_all+0xf8/0x150
       device_unbind_cleanup+0x19/0xd0
      
      //probe path:
      phy_device_register()
        device_add()
      
      phy_connect
        phy_attach_direct() //set device driver
          probe() //it's failed, driver is not bound
          device_bind_driver() // probe failed, it's not called
      
      //remove path:
      phy_device_remove()
        device_del()
          device_release_driver_internal()
            __device_release_driver() //dev->drv is not NULL
              klist_remove() <- knode_driver is not added yet, cause null-ptr-deref
      
      In phy_attach_direct(), after setting the 'dev->driver', probe() fails,
      device_bind_driver() is not called, so the knode_driver->n_klist is not
      set, then it causes null-ptr-deref in __device_release_driver() while
      deleting device. Fix this by setting dev->driver to NULL in the error
      path in phy_attach_direct().
      
      Fixes: e1393456 ("[PATCH] PHY Layer fixup")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      369eb2c9
  4. 25 Nov, 2022 11 commits
  5. 24 Nov, 2022 7 commits