1. 17 Jan, 2023 9 commits
  2. 16 Jan, 2023 7 commits
    • Geetha sowjanya's avatar
      octeontx2-pf: Avoid use of GFP_KERNEL in atomic context · 87b93b67
      Geetha sowjanya authored
      Using GFP_KERNEL in preemption disable context, causing below warning
      when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
      
      [   32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
      [   32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
      [   32.558707] preempt_count: 1, expected: 0
      [   32.562710] RCU nest depth: 0, expected: 0
      [   32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G        W          6.2.0-rc2-00269-gae9dcb91 #7
      [   32.576188] Hardware name: Marvell CN106XX board (DT)
      [   32.581232] Call trace:
      [   32.583670]  dump_backtrace.part.0+0xe0/0xf0
      [   32.587937]  show_stack+0x18/0x30
      [   32.591245]  dump_stack_lvl+0x68/0x84
      [   32.594900]  dump_stack+0x18/0x34
      [   32.598206]  __might_resched+0x12c/0x160
      [   32.602122]  __might_sleep+0x48/0xa0
      [   32.605689]  __kmem_cache_alloc_node+0x2b8/0x2e0
      [   32.610301]  __kmalloc+0x58/0x190
      [   32.613610]  otx2_sq_aura_pool_init+0x1a8/0x314
      [   32.618134]  otx2_open+0x1d4/0x9d0
      
      To avoid use of GFP_ATOMIC for memory allocation, disable preemption
      after all memory allocation is done.
      
      Fixes: 4af1b64f ("octeontx2-pf: Fix lmtst ID used in aura free")
      Signed-off-by: default avatarGeetha sowjanya <gakula@marvell.com>
      Signed-off-by: default avatarSunil Kovvuri Goutham <sgoutham@marvell.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87b93b67
    • David S. Miller's avatar
      Merge branch 'l2tp-races' · 4101971a
      David S. Miller authored
      Cong Wang says:
      
      ====================
      l2tp: fix race conditions in l2tp_tunnel_register()
      
      This patchset contains two patches, the first one is a preparation for
      the second one which is the actual fix. Please find more details in
      each patch description.
      
      I have ran the l2tp test (https://github.com/katalix/l2tp-ktest),
      all test cases are passed.
      
      v3: preserve EEXIST errno for user-space
      v2: move IDR allocation to l2tp_tunnel_register()
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4101971a
    • Cong Wang's avatar
      l2tp: close all race conditions in l2tp_tunnel_register() · 0b2c5972
      Cong Wang authored
      The code in l2tp_tunnel_register() is racy in several ways:
      
      1. It modifies the tunnel socket _after_ publishing it.
      
      2. It calls setup_udp_tunnel_sock() on an existing socket without
         locking.
      
      3. It changes sock lock class on fly, which triggers many syzbot
         reports.
      
      This patch amends all of them by moving socket initialization code
      before publishing and under sock lock. As suggested by Jakub, the
      l2tp lockdep class is not necessary as we can just switch to
      bh_lock_sock_nested().
      
      Fixes: 37159ef2 ("l2tp: fix a lockdep splat")
      Fixes: 6b9f3423 ("l2tp: fix races in tunnel creation")
      Reported-by: syzbot+52866e24647f9a23403f@syzkaller.appspotmail.com
      Reported-by: syzbot+94cc2a66fc228b23f360@syzkaller.appspotmail.com
      Reported-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Guillaume Nault <gnault@redhat.com>
      Cc: Jakub Sitnicki <jakub@cloudflare.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Tom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarCong Wang <cong.wang@bytedance.com>
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b2c5972
    • Cong Wang's avatar
      l2tp: convert l2tp_tunnel_list to idr · c4d48a58
      Cong Wang authored
      l2tp uses l2tp_tunnel_list to track all registered tunnels and
      to allocate tunnel ID's. IDR can do the same job.
      
      More importantly, with IDR we can hold the ID before a successful
      registration so that we don't need to worry about late error
      handling, it is not easy to rollback socket changes.
      
      This is a preparation for the following fix.
      
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Guillaume Nault <gnault@redhat.com>
      Cc: Jakub Sitnicki <jakub@cloudflare.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Tom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarCong Wang <cong.wang@bytedance.com>
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4d48a58
    • Eric Dumazet's avatar
      net/sched: sch_taprio: fix possible use-after-free · 3a415d59
      Eric Dumazet authored
      syzbot reported a nasty crash [1] in net_tx_action() which
      made little sense until we got a repro.
      
      This repro installs a taprio qdisc, but providing an
      invalid TCA_RATE attribute.
      
      qdisc_create() has to destroy the just initialized
      taprio qdisc, and taprio_destroy() is called.
      
      However, the hrtimer used by taprio had already fired,
      therefore advance_sched() called __netif_schedule().
      
      Then net_tx_action was trying to use a destroyed qdisc.
      
      We can not undo the __netif_schedule(), so we must wait
      until one cpu serviced the qdisc before we can proceed.
      
      Many thanks to Alexander Potapenko for his help.
      
      [1]
      BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
      BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
      BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
      BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
       queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
       do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
       __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
       _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
       spin_trylock include/linux/spinlock.h:359 [inline]
       qdisc_run_begin include/net/sch_generic.h:187 [inline]
       qdisc_run+0xee/0x540 include/net/pkt_sched.h:125
       net_tx_action+0x77c/0x9a0 net/core/dev.c:5086
       __do_softirq+0x1cc/0x7fb kernel/softirq.c:571
       run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934
       smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164
       kthread+0x31b/0x430 kernel/kthread.c:376
       ret_from_fork+0x1f/0x30
      
      Uninit was created at:
       slab_post_alloc_hook mm/slab.h:732 [inline]
       slab_alloc_node mm/slub.c:3258 [inline]
       __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970
       kmalloc_reserve net/core/skbuff.c:358 [inline]
       __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430
       alloc_skb include/linux/skbuff.h:1257 [inline]
       nlmsg_new include/net/netlink.h:953 [inline]
       netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436
       netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507
       rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108
       netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
       netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
       netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
       sock_sendmsg_nosec net/socket.c:714 [inline]
       sock_sendmsg net/socket.c:734 [inline]
       ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482
       ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536
       __sys_sendmsg net/socket.c:2565 [inline]
       __do_sys_sendmsg net/socket.c:2574 [inline]
       __se_sys_sendmsg net/socket.c:2572 [inline]
       __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
      
      Fixes: 5a781ccb ("tc: Add support for configuring the taprio scheduler")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a415d59
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf · 21705c77
      David S. Miller authored
      Pable Neira Ayuso says:
      
      ====================
      
      The following patchset contains Netfilter fixes for net:
      
      1) Increase timeout to 120 seconds for netfilter selftests to fix
         nftables transaction tests, from Florian Westphal.
      
      2) Fix overflow in bitmap_ip_create() due to integer arithmetics
         in a 64-bit bitmask, from Gavrilov Ilia.
      
      3) Fix incorrect arithmetics in nft_payload with double-tagged
         vlan matching.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21705c77
    • Kurt Kanzenbach's avatar
      net: stmmac: Fix queue statistics reading · c296c77e
      Kurt Kanzenbach authored
      Correct queue statistics reading. All queue statistics are stored as unsigned
      long values. The retrieval for ethtool fetches these values as u64. However, on
      some systems the size of the counters are 32 bit. That yields wrong queue
      statistic counters e.g., on arm32 systems such as the stm32mp157. Fix it by
      using the correct data type.
      
      Tested on Olimex STMP157-OLinuXino-LIME2 by simple running linuxptp for a short
      period of time:
      
      Non-patched kernel:
      |root@st1:~# ethtool -S eth0 | grep q0
      |     q0_tx_pkt_n: 3775276254951 # ???
      |     q0_tx_irq_n: 879
      |     q0_rx_pkt_n: 1194000908909 # ???
      |     q0_rx_irq_n: 278
      
      Patched kernel:
      |root@st1:~# ethtool -S eth0 | grep q0
      |     q0_tx_pkt_n: 2434
      |     q0_tx_irq_n: 1274
      |     q0_rx_pkt_n: 1604
      |     q0_rx_irq_n: 846
      
      Fixes: 68e9c5de ("net: stmmac: add ethtool per-queue statistic framework")
      Signed-off-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Cc: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
      Cc: Wong Vee Khee <vee.khee.wong@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c296c77e
  3. 14 Jan, 2023 9 commits
    • Rahul Rameshbabu's avatar
      sch_htb: Avoid grafting on htb_destroy_class_offload when destroying htb · a22b7388
      Rahul Rameshbabu authored
      Peek at old qdisc and graft only when deleting a leaf class in the htb,
      rather than when deleting the htb itself. Do not peek at the qdisc of the
      netdev queue when destroying the htb. The caller may already have grafted a
      new qdisc that is not part of the htb structure being destroyed.
      
      This fix resolves two use cases.
      
        1. Using tc to destroy the htb.
          - Netdev was being prematurely activated before the htb was fully
            destroyed.
        2. Using tc to replace the htb with another qdisc (which also leads to
           the htb being destroyed).
          - Premature netdev activation like previous case. Newly grafted qdisc
            was also getting accidentally overwritten when destroying the htb.
      
      Fixes: d03b195b ("sch_htb: Hierarchical QoS hardware offload")
      Signed-off-by: default avatarRahul Rameshbabu <rrameshbabu@nvidia.com>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maxtram95@gmail.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Link: https://lore.kernel.org/r/20230113005528.302625-1-rrameshbabu@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a22b7388
    • Jakub Kicinski's avatar
      Merge branch 'mptcp-userspace-pm-create-sockets-for-the-right-family' · da263fcb
      Jakub Kicinski authored
      Matthieu Baerts says:
      
      ====================
      mptcp: userspace pm: create sockets for the right family
      
      Before these patches, the Userspace Path Manager would allow the
      creation of subflows with wrong families: taking the one of the MPTCP
      socket instead of the provided ones and resulting in the creation of
      subflows with likely not the right source and/or destination IPs. It
      would also allow the creation of subflows between different families or
      not respecting v4/v6-only socket attributes.
      
      Patch 1 lets the userspace PM select the proper family to avoid creating
      subflows with the wrong source and/or destination addresses because the
      family is not the expected one.
      
      Patch 2 makes sure the userspace PM doesn't allow the userspace to
      create subflows for a family that is not allowed.
      
      Patch 3 validates scenarios with a mix of v4 and v6 subflows for the
      same MPTCP connection.
      
      These patches fix issues introduced in v5.19 when the userspace path
      manager has been introduced.
      ====================
      
      Link: https://lore.kernel.org/r/20230112-upstream-net-20230112-netlink-v4-v6-v1-0-6a8363a221d2@tessares.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      da263fcb
    • Matthieu Baerts's avatar
      selftests: mptcp: userspace: validate v4-v6 subflows mix · 4656d72c
      Matthieu Baerts authored
      MPTCP protocol supports having subflows in both IPv4 and IPv6. In Linux,
      it is possible to have that if the MPTCP socket has been created with
      AF_INET6 family without the IPV6_V6ONLY option.
      
      Here, a new IPv4 subflow is being added to the initial IPv6 connection,
      then being removed using Netlink commands.
      
      Cc: stable@vger.kernel.org # v5.19+
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4656d72c
    • Matthieu Baerts's avatar
      mptcp: netlink: respect v4/v6-only sockets · fb00ee4f
      Matthieu Baerts authored
      If an MPTCP socket has been created with AF_INET6 and the IPV6_V6ONLY
      option has been set, the userspace PM would allow creating subflows
      using IPv4 addresses, e.g. mapped in v6.
      
      The kernel side of userspace PM will also accept creating subflows with
      local and remote addresses having different families. Depending on the
      subflow socket's family, different behaviours are expected:
       - If AF_INET is forced with a v6 address, the kernel will take the last
         byte of the IP and try to connect to that: a new subflow is created
         but to a non expected address.
       - If AF_INET6 is forced with a v4 address, the kernel will try to
         connect to a v4 address (v4-mapped-v6). A -EBADF error from the
         connect() part is then expected.
      
      It is then required to check the given families can be accepted. This is
      done by using a new helper for addresses family matching, taking care of
      IPv4 vs IPv4-mapped-IPv6 addresses. This helper will be re-used later by
      the in-kernel path-manager to use mixed IPv4 and IPv6 addresses.
      
      While at it, a clear error message is now reported if there are some
      conflicts with the families that have been passed by the userspace.
      
      Fixes: 702c2f64 ("mptcp: netlink: allow userspace-driven subflow establishment")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fb00ee4f
    • Paolo Abeni's avatar
      mptcp: explicitly specify sock family at subflow creation time · 6bc1fe7d
      Paolo Abeni authored
      Let the caller specify the to-be-created subflow family.
      
      For a given MPTCP socket created with the AF_INET6 family, the current
      userspace PM can already ask the kernel to create subflows in v4 and v6.
      If "plain" IPv4 addresses are passed to the kernel, they are
      automatically mapped in v6 addresses "by accident". This can be
      problematic because the userspace will need to pass different addresses,
      now the v4-mapped-v6 addresses to destroy this new subflow.
      
      On the other hand, if the MPTCP socket has been created with the AF_INET
      family, the command to create a subflow in v6 will be accepted but the
      result will not be the one as expected as new subflow will be created in
      IPv4 using part of the v6 addresses passed to the kernel: not creating
      the expected subflow then.
      
      No functional change intended for the in-kernel PM where an explicit
      enforcement is currently in place. This arbitrary enforcement will be
      leveraged by other patches in a future version.
      
      Fixes: 702c2f64 ("mptcp: netlink: allow userspace-driven subflow establishment")
      Cc: stable@vger.kernel.org
      Co-developed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6bc1fe7d
    • Clément Léger's avatar
      net: lan966x: add missing fwnode_handle_put() for ports node · 925f3deb
      Clément Léger authored
      Since the "ethernet-ports" node is retrieved using
      device_get_named_child_node(), it should be release after using it. Add
      missing fwnode_handle_put() and move the code that retrieved the node
      from device-tree to avoid complicated handling in case of error.
      
      Fixes: db8bcaad ("net: lan966x: add the basic lan966x driver")
      Signed-off-by: default avatarClément Léger <clement.leger@bootlin.com>
      Reviewed-by: default avatarAlexander Duyck <alexanderduyck@fb.com>
      Link: https://lore.kernel.org/r/20230112161311.495124-1-clement.leger@bootlin.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      925f3deb
    • Vladimir Oltean's avatar
      net: enetc: avoid deadlock in enetc_tx_onestep_tstamp() · 3c463721
      Vladimir Oltean authored
      This lockdep splat says it better than I could:
      
      ================================
      WARNING: inconsistent lock state
      6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
      --------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
      ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0
      {IN-SOFTIRQ-W} state was registered at:
        _raw_spin_lock+0x5c/0xc0
        sch_direct_xmit+0x148/0x37c
        __dev_queue_xmit+0x528/0x111c
        ip6_finish_output2+0x5ec/0xb7c
        ip6_finish_output+0x240/0x3f0
        ip6_output+0x78/0x360
        ndisc_send_skb+0x33c/0x85c
        ndisc_send_rs+0x54/0x12c
        addrconf_rs_timer+0x154/0x260
        call_timer_fn+0xb8/0x3a0
        __run_timers.part.0+0x214/0x26c
        run_timer_softirq+0x3c/0x74
        __do_softirq+0x14c/0x5d8
        ____do_softirq+0x10/0x20
        call_on_irq_stack+0x2c/0x5c
        do_softirq_own_stack+0x1c/0x30
        __irq_exit_rcu+0x168/0x1a0
        irq_exit_rcu+0x10/0x40
        el1_interrupt+0x38/0x64
      irq event stamp: 7825
      hardirqs last  enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130
      hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8
      softirqs last  enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8
      softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(_xmit_ETHER#2);
        <Interrupt>
          lock(_xmit_ETHER#2);
      
       *** DEADLOCK ***
      
      3 locks held by kworker/1:3/179:
       #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
       #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
       #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34
      
      Workqueue: events enetc_tx_onestep_tstamp
      Call trace:
       print_usage_bug.part.0+0x208/0x22c
       mark_lock+0x7f0/0x8b0
       __lock_acquire+0x7c4/0x1ce0
       lock_acquire.part.0+0xe0/0x220
       lock_acquire+0x68/0x84
       _raw_spin_lock+0x5c/0xc0
       netif_freeze_queues+0x5c/0xc0
       netif_tx_lock+0x24/0x34
       enetc_tx_onestep_tstamp+0x20/0x100
       process_one_work+0x28c/0x6c0
       worker_thread+0x74/0x450
       kthread+0x118/0x11c
      
      but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in
      process context, therefore with softirqs enabled (i.o.w., it can be
      interrupted by a softirq). If we hold the netif_tx_lock() when there is
      an interrupt, and the NET_TX softirq then gets scheduled, this will take
      the netif_tx_lock() a second time and deadlock the kernel.
      
      To solve this, use netif_tx_lock_bh(), which blocks softirqs from
      running.
      
      Fixes: 7294380c ("enetc: support PTP Sync packet one-step timestamping")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAlexander Duyck <alexanderduyck@fb.com>
      Link: https://lore.kernel.org/r/20230112105440.1786799-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3c463721
    • Esina Ekaterina's avatar
      net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs · 488e0bf7
      Esina Ekaterina authored
      If uhdlc_priv_tsa != 1 then utdm is not initialized.
      And if ret != NULL then goto undo_uhdlc_init, where
      utdm is dereferenced. Same if dev == NULL.
      
      Found by Astra Linux on behalf of Linux Verification Center
      (linuxtesting.org) with SVACE.
      
      Fixes: 8d68100a ("soc/fsl/qe: fix err handling of ucc_of_parse_tdm")
      Signed-off-by: default avatarEsina Ekaterina <eesina@astralinux.ru>
      Link: https://lore.kernel.org/r/20230112074703.13558-1-eesina@astralinux.ruSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      488e0bf7
    • Jisoo Jang's avatar
      net: nfc: Fix use-after-free in local_cleanup() · 4bb4db7f
      Jisoo Jang authored
      Fix a use-after-free that occurs in kfree_skb() called from
      local_cleanup(). This could happen when killing nfc daemon (e.g. neard)
      after detaching an nfc device.
      When detaching an nfc device, local_cleanup() called from
      nfc_llcp_unregister_device() frees local->rx_pending and decreases
      local->ref by kref_put() in nfc_llcp_local_put().
      In the terminating process, nfc daemon releases all sockets and it leads
      to decreasing local->ref. After the last release of local->ref,
      local_cleanup() called from local_release() frees local->rx_pending
      again, which leads to the bug.
      
      Setting local->rx_pending to NULL in local_cleanup() could prevent
      use-after-free when local_cleanup() is called twice.
      
      Found by a modified version of syzkaller.
      
      BUG: KASAN: use-after-free in kfree_skb()
      
      Call Trace:
      dump_stack_lvl (lib/dump_stack.c:106)
      print_address_description.constprop.0.cold (mm/kasan/report.c:306)
      kasan_check_range (mm/kasan/generic.c:189)
      kfree_skb (net/core/skbuff.c:955)
      local_cleanup (net/nfc/llcp_core.c:159)
      nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)
      nfc_llcp_local_put (net/nfc/llcp_core.c:181)
      llcp_sock_destruct (net/nfc/llcp_sock.c:959)
      __sk_destruct (net/core/sock.c:2133)
      sk_destruct (net/core/sock.c:2181)
      __sk_free (net/core/sock.c:2192)
      sk_free (net/core/sock.c:2203)
      llcp_sock_release (net/nfc/llcp_sock.c:646)
      __sock_release (net/socket.c:650)
      sock_close (net/socket.c:1365)
      __fput (fs/file_table.c:306)
      task_work_run (kernel/task_work.c:179)
      ptrace_notify (kernel/signal.c:2354)
      syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)
      syscall_exit_to_user_mode (kernel/entry/common.c:296)
      do_syscall_64 (arch/x86/entry/common.c:86)
      entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)
      
      Allocated by task 4719:
      kasan_save_stack (mm/kasan/common.c:45)
      __kasan_slab_alloc (mm/kasan/common.c:325)
      slab_post_alloc_hook (mm/slab.h:766)
      kmem_cache_alloc_node (mm/slub.c:3497)
      __alloc_skb (net/core/skbuff.c:552)
      pn533_recv_response (drivers/nfc/pn533/usb.c:65)
      __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)
      usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)
      tasklet_action_common.isra.0 (kernel/softirq.c:797)
      __do_softirq (kernel/softirq.c:571)
      
      Freed by task 1901:
      kasan_save_stack (mm/kasan/common.c:45)
      kasan_set_track (mm/kasan/common.c:52)
      kasan_save_free_info (mm/kasan/genericdd.c:518)
      __kasan_slab_free (mm/kasan/common.c:236)
      kmem_cache_free (mm/slub.c:3809)
      kfree_skbmem (net/core/skbuff.c:874)
      kfree_skb (net/core/skbuff.c:931)
      local_cleanup (net/nfc/llcp_core.c:159)
      nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)
      nfc_unregister_device (net/nfc/core.c:1179)
      pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)
      pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)
      usb_unbind_interface (drivers/usb/core/driver.c:458)
      device_release_driver_internal (drivers/base/dd.c:1279)
      bus_remove_device (drivers/base/bus.c:529)
      device_del (drivers/base/core.c:3665)
      usb_disable_device (drivers/usb/core/message.c:1420)
      usb_disconnect (drivers/usb/core.c:2261)
      hub_event (drivers/usb/core/hub.c:5833)
      process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)
      worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)
      kthread (kernel/kthread.c:319)
      ret_from_fork (arch/x86/entry/entry_64.S:301)
      
      Fixes: 3536da06 ("NFC: llcp: Clean local timers and works when removing a device")
      Signed-off-by: default avatarJisoo Jang <jisoo.jang@yonsei.ac.kr>
      Link: https://lore.kernel.org/r/20230111131914.3338838-1-jisoo.jang@yonsei.ac.krSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4bb4db7f
  4. 13 Jan, 2023 7 commits
  5. 12 Jan, 2023 8 commits
    • Linus Torvalds's avatar
      Merge tag 's390-6.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 5be413a6
      Linus Torvalds authored
      Pull s390 fixes from Heiko Carstens:
      
       - Add various missing READ_ONCE() to cmpxchg() loops prevent the
         compiler from potentially generating incorrect code. This includes a
         rather large change to the s390 specific hardware sampling code and
         its current use of cmpxchg_double().
      
         Do the fix now to get it out of the way of Peter Zijlstra's
         cmpxchg128() work, and have something that can be backported. The
         added new code includes a private 128 bit cmpxchg variant which will
         be removed again after Peter's rework is available. Also note that
         this 128 bit cmpxchg variant is used to implement 128 bit
         READ_ONCE(), while strictly speaking it wouldn't be necessary, and
         _READ_ONCE() should also be sufficient; even though it isn't obvious
         for all converted locations that this is the case. Therefore use this
         implementation for for the sake of clarity and consistency for now.
      
       - Fix ipl report address handling to avoid kdump failures/hangs.
      
       - Fix misuse of #(el)if in kernel decompressor.
      
       - Define RUNTIME_DISCARD_EXIT to fix link error with GNU ld < 2.36,
         caused by the recently changed discard behaviour.
      
       - Make sure _edata and _end symbols are always page aligned.
      
       - The current header guard DEBUG_H in one of the s390 specific header
         files is too generic and conflicts with the ath9k wireless driver.
         Add an _ASM_S390_ prefix to the guard to make it unique.
      
       - Update defconfigs.
      
      * tag 's390-6.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390: update defconfigs
        KVM: s390: interrupt: use READ_ONCE() before cmpxchg()
        s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple()
        s390/cpum_sf: add READ_ONCE() semantics to compare and swap loops
        s390/kexec: fix ipl report address for kdump
        s390: fix -Wundef warning for CONFIG_KERNEL_ZSTD
        s390: define RUNTIME_DISCARD_EXIT to fix link error with GNU ld < 2.36
        s390: expicitly align _edata and _end symbols on page boundary
        s390/debug: add _ASM_S390_ prefix to header guard
      5be413a6
    • Linus Torvalds's avatar
      Merge tag 'for-linus-6.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · bad8c4a8
      Linus Torvalds authored
      Pull xen fixes from Juergen Gross:
      
       - two cleanup patches
      
       - a fix of a memory leak in the Xen pvfront driver
      
       - a fix of a locking issue in the Xen hypervisor console driver
      
      * tag 'for-linus-6.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        xen/pvcalls: free active map buffer on pvcalls_front_free_map
        hvc/xen: lock console list traversal
        x86/xen: Remove the unused function p2m_index()
        xen: make remove callback of xen driver void returned
      bad8c4a8
    • Linus Torvalds's avatar
      Merge tag 'timers-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 772d0e91
      Linus Torvalds authored
      Pull timer doc fixes from Ingo Molnar:
      
       - Fix various DocBook formatting errors in kernel/time/ that generated
         (justified) warnings during a kernel-doc build.
      
      * tag 'timers-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        time: Fix various kernel-doc problems
      772d0e91
    • Linus Torvalds's avatar
      Merge tag 'perf-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a7b19c60
      Linus Torvalds authored
      Pull perf events hw enablement from Ingo Molnar:
      
       - More hardware-enablement for Intel Meteor Lake & Emerald Rapid
         systems: pure model ID enumeration additions that do not affect other
         systems.
      
      * tag 'perf-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/x86/intel/uncore: Add Emerald Rapids
        perf/x86/msr: Add Emerald Rapids
        perf/x86/msr: Add Meteor Lake support
        perf/x86/cstate: Add Meteor Lake support
      a7b19c60
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · ea66bf86
      Linus Torvalds authored
      Pull scheduler fixes from Ingo Molnar:
      
       - Fix scheduler frequency invariance bug related to overly long
         tickless periods triggering an integer overflow and disabling the
         feature.
      
       - Fix use-after-free bug in dup_user_cpus_ptr().
      
       - Fix do_set_cpus_allowed() deadlock scenarios related to calling
         kfree() with the pi_lock held. NOTE: the rcu_free() is the 'lazy'
         solution here - we looked at patches to free the structure after the
         pi_lock got dropped, but that looked quite a bit messier - and none
         of this is truly performance critical. We can revisit this if it's
         too lazy of a solution ...
      
      * tag 'sched-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/core: Use kfree_rcu() in do_set_cpus_allowed()
        sched/core: Fix use-after-free bug in dup_user_cpus_ptr()
        sched/core: Fix arch_scale_freq_tick() on tickless systems
      ea66bf86
    • Linus Torvalds's avatar
      Merge tag 'core-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · cf4d5be8
      Linus Torvalds authored
      Pull objtool fix from Ingo Molnar:
      
       - Fix objtool to be more permissive with hand-written assembly that
         uses non-function symbols in executable sections.
      
      * tag 'core-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        objtool: Tolerate STT_NOTYPE symbols at end of section
      cf4d5be8
    • Linus Torvalds's avatar
      Merge tag 'urgent-nolibc.2023.01.09a' of... · f129b616
      Linus Torvalds authored
      Merge tag 'urgent-nolibc.2023.01.09a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
      
      Pull nolibc fixes from Paul McKenney:
      
       - The fd_set structure was incorrectly defined as arrays of u32 instead
         of long, which breaks BE64. Fix courtesy of Sven Schnelle.
      
       - S_ISxxx macros were incorrectly testing the bits after applying them
         instead of bitwise ANDing S_FMT with the value. Fix from Warner Losh.
      
       - The mips code was randomly broken due to an unprotected "noreorder"
         directive in the _start code that could prevent the assembler from
         filling delayed slots. This in turn resulted in random other
         instructions being placed into those slots. Fix courtesy of Willy
         Tarreau.
      
       - The current nolibc header layout refrains from including files that
         are not explicitly included by the code using nolibc. Unfortunately,
         this causes build failures when such files contain definitions that
         are used (for example) by libgcc. Example definitions include raise()
         and memset(), which are called by some architectures, but only at
         certain optimization levels. Fix courtesy of Willy Tarreau.
      
       - gcc 11.3 in ARM thumb2 mode at -O2 recognized a memset() construction
         inside the memset() definition. The compiler replaced this
         construction with a call to... memset(). Userland cannot be forced to
         build with -ffreestanding, so an empty asm() statement was introduced
         into the loop the loop in order to prevent the compiler from making
         this unproductive transformation. Fix courtesy of Willy Tarreau.
      
       - Most of the O_* macros were wrong on RISCV because their octal values
         were coded as hexadecimal. This resulted in the getdents64() selftest
         failing. Fix courtesy of Willy Tarreau.
      
      This was tested on x86_64, i386, armv5, armv7, thumb1, thumb2, mips and
      riscv, all at -O0, -Os and -O3.
      
      * tag 'urgent-nolibc.2023.01.09a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
        tools/nolibc: fix the O_* fcntl/open macro definitions for riscv
        tools/nolibc: prevent gcc from making memset() loop over itself
        tools/nolibc: fix missing includes causing build issues at -O0
        tools/nolibc: restore mips branch ordering in the _start block
        tools/nolibc: Fix S_ISxxx macros
        nolibc: fix fd_set type
      f129b616
    • Andre Przywara's avatar
      r8152: add vendor/device ID pair for Microsoft Devkit · be53771c
      Andre Przywara authored
      The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
      Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
      machines, Microsoft uses a custom USB device ID.
      
      Add the respective ID values to the driver. This makes Ethernet work on
      the MS Devkit device. The chip has been visually confirmed to be a
      RTL8153.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Link: https://lore.kernel.org/r/20230111133228.190801-1-andre.przywara@arm.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      be53771c