commit 2e3d9118e4e62b90603d61abd45d8bb29ebe7920
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Feb 25 11:51:51 2023 +0100

    Linux 4.19.274
    
    Link: https://lore.kernel.org/r/20230223130424.079732181@linuxfoundation.org
    Link: https://lore.kernel.org/r/20230223141538.102388120@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Slade Watkins <srw@sladewatkins.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7603df97635954165fb599e64e197efc353979b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Feb 22 09:52:32 2023 -0800

    bpf: add missing header file include
    
    commit f3dd0c53370e70c0f9b7e931bbec12916f3bb8cc upstream.
    
    Commit 74e19ef0ff80 ("uaccess: Add speculation barrier to
    copy_from_user()") built fine on x86-64 and arm64, and that's the extent
    of my local build testing.
    
    It turns out those got the <linux/nospec.h> include incidentally through
    other header files (<linux/kvm_host.h> in particular), but that was not
    true of other architectures, resulting in build errors
    
      kernel/bpf/core.c: In function ‘___bpf_prog_run’:
      kernel/bpf/core.c:1913:3: error: implicit declaration of function ‘barrier_nospec’
    
    so just make sure to explicitly include the proper <linux/nospec.h>
    header file to make everybody see it.
    
    Fixes: 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Viresh Kumar <viresh.kumar@linaro.org>
    Reported-by: Huacai Chen <chenhuacai@loongson.cn>
    Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Tested-by: Dave Hansen <dave.hansen@linux.intel.com>
    Acked-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b69cdd9f9a7f596e3dd31f05f9852940d177924
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jan 4 13:09:12 2023 -0800

    ext4: Fix function prototype mismatch for ext4_feat_ktype
    
    commit 118901ad1f25d2334255b3d50512fa20591531cd upstream.
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed.
    
    ext4_feat_ktype was setting the "release" handler to "kfree", which
    doesn't have a matching function prototype. Add a simple wrapper
    with the correct prototype.
    
    This was found as a result of Clang's new -Wcast-function-type-strict
    flag, which is more sensitive than the simpler -Wcast-function-type,
    which only checks for type width mismatches.
    
    Note that this code is only reached when ext4 is a loadable module and
    it is being unloaded:
    
     CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)
     ...
     RIP: 0010:kobject_put+0xbb/0x1b0
     ...
     Call Trace:
      <TASK>
      ext4_exit_sysfs+0x14/0x60 [ext4]
      cleanup_module+0x67/0xedb [ext4]
    
    Fixes: b99fee58a20a ("ext4: create ext4_feat kobject dynamically")
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Eric Biggers <ebiggers@kernel.org>
    Cc: stable@vger.kernel.org
    Build-tested-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20230103234616.never.915-kees@kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20230104210908.gonna.388-kees@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27d44d6fd744a5d14db11886db3643062828315a
Author: Lukas Wunner <lukas@wunner.de>
Date:   Fri Jan 27 15:01:00 2023 +0100

    wifi: mwifiex: Add missing compatible string for SD8787
    
    commit 36dd7a4c6226133b0b7aa92b8e604e688d958d0c upstream.
    
    Commit e3fffc1f0b47 ("devicetree: document new marvell-8xxx and
    pwrseq-sd8787 options") documented a compatible string for SD8787 in
    the devicetree bindings, but neglected to add it to the mwifiex driver.
    
    Fixes: e3fffc1f0b47 ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v4.11+
    Cc: Matt Ranostay <mranostay@ti.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/320de5005ff3b8fd76be2d2b859fd021689c3681.1674827105.git.lukas@wunner.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8e54da1c729cc23d9a7b7bd42379323e7fb7979
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date:   Tue Feb 21 12:30:15 2023 -0800

    uaccess: Add speculation barrier to copy_from_user()
    
    commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47 upstream.
    
    The results of "access_ok()" can be mis-speculated.  The result is that
    you can end speculatively:
    
            if (access_ok(from, size))
                    // Right here
    
    even for bad from/size combinations.  On first glance, it would be ideal
    to just add a speculation barrier to "access_ok()" so that its results
    can never be mis-speculated.
    
    But there are lots of system calls just doing access_ok() via
    "copy_to_user()" and friends (example: fstat() and friends).  Those are
    generally not problematic because they do not _consume_ data from
    userspace other than the pointer.  They are also very quick and common
    system calls that should not be needlessly slowed down.
    
    "copy_from_user()" on the other hand uses a user-controller pointer and
    is frequently followed up with code that might affect caches.  Take
    something like this:
    
            if (!copy_from_user(&kernelvar, uptr, size))
                    do_something_with(kernelvar);
    
    If userspace passes in an evil 'uptr' that *actually* points to a kernel
    addresses, and then do_something_with() has cache (or other)
    side-effects, it could allow userspace to infer kernel data values.
    
    Add a barrier to the common copy_from_user() code to prevent
    mis-speculated values which happen after the copy.
    
    Also add a stub for architectures that do not define barrier_nospec().
    This makes the macro usable in generic code.
    
    Since the barrier is now usable in generic code, the x86 #ifdef in the
    BPF code can also go away.
    
    Reported-by: Jordy Zomer <jordyzomer@google.com>
    Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>   # BPF bits
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e936e3fd614f0b262780a762c2d6008d6c672991
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Dec 30 22:55:47 2021 +0300

    mac80211: mesh: embedd mesh_paths and mpp_paths into ieee80211_if_mesh
    
    commit 8b5cb7e41d9d77ffca036b0239177de123394a55 upstream.
    
    Syzbot hit NULL deref in rhashtable_free_and_destroy(). The problem was
    in mesh_paths and mpp_paths being NULL.
    
    mesh_pathtbl_init() could fail in case of memory allocation failure, but
    nobody cared, since ieee80211_mesh_init_sdata() returns void. It led to
    leaving 2 pointers as NULL. Syzbot has found null deref on exit path,
    but it could happen anywhere else, because code assumes these pointers are
    valid.
    
    Since all ieee80211_*_setup_sdata functions are void and do not fail,
    let's embedd mesh_paths and mpp_paths into parent struct to avoid
    adding error handling on higher levels and follow the pattern of others
    setup_sdata functions
    
    Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable")
    Reported-and-tested-by: syzbot+860268315ba86ea6b96b@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/20211230195547.23977-1-paskripkin@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [pchelkin@ispras.ru: adapt a comment spell fixing issue]
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5245a6cf83ca5c4b68d643f8b31ed0eb127126e
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Fri Dec 30 00:56:41 2022 +0800

    drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
    
    commit 4a61648af68f5ba4884f0e3b494ee1cabc4b6620 upstream.
    
    If intel_gvt_dma_map_guest_page failed, it will call
    ppgtt_invalidate_spt, which will finally free the spt.
    But the caller function ppgtt_populate_spt_by_guest_entry
    does not notice that, it will free spt again in its error
    path.
    
    Fix this by canceling the mapping of DMA address and freeing sub_spt.
    Besides, leave the handle of spt destroy to caller function instead
    of callee function when error occurs.
    
    Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20221229165641.1192455-1-zyytlz.wz@163.com
    Signed-off-by: Ovidiu Panait <ovidiu.panait@eng.windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6a300076d11a6e27b4d4f7fd986ec66ee97a3e1
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Feb 9 23:25:49 2023 +0100

    alarmtimer: Prevent starvation by small intervals and SIG_IGN
    
    commit d125d1349abeb46945dc5e98f7824bf688266f13 upstream.
    
    syzbot reported a RCU stall which is caused by setting up an alarmtimer
    with a very small interval and ignoring the signal. The reproducer arms the
    alarm timer with a relative expiry of 8ns and an interval of 9ns. Not a
    problem per se, but that's an issue when the signal is ignored because then
    the timer is immediately rearmed because there is no way to delay that
    rearming to the signal delivery path.  See posix_timer_fn() and commit
    58229a189942 ("posix-timers: Prevent softirq starvation by small intervals
    and SIG_IGN") for details.
    
    The reproducer does not set SIG_IGN explicitely, but it sets up the timers
    signal with SIGCONT. That has the same effect as explicitely setting
    SIG_IGN for a signal as SIGCONT is ignored if there is no handler set and
    the task is not ptraced.
    
    The log clearly shows that:
    
       [pid  5102] --- SIGCONT {si_signo=SIGCONT, si_code=SI_TIMER, si_timerid=0, si_overrun=316014, si_int=0, si_ptr=NULL} ---
    
    It works because the tasks are traced and therefore the signal is queued so
    the tracer can see it, which delays the restart of the timer to the signal
    delivery path. But then the tracer is killed:
    
       [pid  5087] kill(-5102, SIGKILL <unfinished ...>
       ...
       ./strace-static-x86_64: Process 5107 detached
    
    and after it's gone the stall can be observed:
    
       syzkaller login: [   79.439102][    C0] hrtimer: interrupt took 68471 ns
       [  184.460538][    C1] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
       ...
       [  184.658237][    C1] rcu: Stack dump where RCU GP kthread last ran:
       [  184.664574][    C1] Sending NMI from CPU 1 to CPUs 0:
       [  184.669821][    C0] NMI backtrace for cpu 0
       [  184.669831][    C0] CPU: 0 PID: 5108 Comm: syz-executor192 Not tainted 6.2.0-rc6-next-20230203-syzkaller #0
       ...
       [  184.670036][    C0] Call Trace:
       [  184.670041][    C0]  <IRQ>
       [  184.670045][    C0]  alarmtimer_fired+0x327/0x670
    
    posix_timer_fn() prevents that by checking whether the interval for
    timers which have the signal ignored is smaller than a jiffie and
    artifically delay it by shifting the next expiry out by a jiffie. That's
    accurate vs. the overrun accounting, but slightly inaccurate
    vs. timer_gettimer(2).
    
    The comment in that function says what needs to be done and there was a fix
    available for the regular userspace induced SIG_IGN mechanism, but that did
    not work due to the implicit ignore for SIGCONT and similar signals. This
    needs to be worked on, but for now the only available workaround is to do
    exactly what posix_timer_fn() does:
    
    Increase the interval of self-rearming timers, which have their signal
    ignored, to at least a jiffie.
    
    Interestingly this has been fixed before via commit ff86bf0c65f1
    ("alarmtimer: Rate limit periodic intervals") already, but that fix got
    lost in a later rework.
    
    Reported-by: syzbot+b9564ba6e8e00694511b@syzkaller.appspotmail.com
    Fixes: f2c45807d399 ("alarmtimer: Switch over to generic set/get/rearm routine")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: John Stultz <jstultz@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87k00q1no2.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63ad0ad1352e3447cb14072e6b621b5af384ff13
Author: Sean Anderson <sean.anderson@seco.com>
Date:   Fri Dec 16 12:29:37 2022 -0500

    powerpc: dts: t208x: Disable 10G on MAC1 and MAC2
    
    [ Upstream commit 8d8bee13ae9e316443c6666286360126a19c8d94 ]
    
    There aren't enough resources to run these ports at 10G speeds. Disable
    10G for these ports, reverting to the previous speed.
    
    Fixes: 36926a7d70c2 ("powerpc: dts: t208x: Mark MAC1 and MAC2 as 10G")
    Reported-by: Camelia Alexandra Groza <camelia.groza@nxp.com>
    Signed-off-by: Sean Anderson <sean.anderson@seco.com>
    Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
    Tested-by: Camelia Groza <camelia.groza@nxp.com>
    Link: https://lore.kernel.org/r/20221216172937.2960054-1-sean.anderson@seco.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8144445c0bb7b67229afde78befe06f37332d6b
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Mon Dec 19 11:39:27 2022 +0100

    can: kvaser_usb: hydra: help gcc-13 to figure out cmd_len
    
    [ Upstream commit f006229135b7debf4037adb1eb93e358559593db ]
    
    Debian's gcc-13 [1] throws the following error in
    kvaser_usb_hydra_cmd_size():
    
    [1] gcc version 13.0.0 20221214 (experimental) [master r13-4693-g512098a3316] (Debian 13-20221214-1)
    
    | drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c:502:65: error:
    | array subscript ‘struct kvaser_cmd_ext[0]’ is partly outside array
    | bounds of ‘unsigned char[32]’ [-Werror=array-bounds=]
    |   502 |                 ret = le16_to_cpu(((struct kvaser_cmd_ext *)cmd)->len);
    
    kvaser_usb_hydra_cmd_size() returns the size of given command. It
    depends on the command number (cmd->header.cmd_no). For extended
    commands (cmd->header.cmd_no == CMD_EXTENDED) the above shown code is
    executed.
    
    Help gcc to recognize that this code path is not taken in all cases,
    by calling kvaser_usb_hydra_cmd_size() directly after assigning the
    command number.
    
    Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family")
    Cc: Jimmy Assarsson <extja@kvaser.com>
    Cc: Anssi Hannula <anssi.hannula@bitwise.fi>
    Link: https://lore.kernel.org/all/20221219110104.1073881-1-mkl@pengutronix.de
    Tested-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4935368448ce8097dada35163598e93567f1110
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Jun 1 22:45:33 2022 +0200

    random: always mix cycle counter in add_latent_entropy()
    
    [ Upstream commit d7bf7f3b813e3755226bcb5114ad2ac477514ebf ]
    
    add_latent_entropy() is called every time a process forks, in
    kernel_clone(). This in turn calls add_device_randomness() using the
    latent entropy global state. add_device_randomness() does two things:
    
       2) Mixes into the input pool the latent entropy argument passed; and
       1) Mixes in a cycle counter, a sort of measurement of when the event
          took place, the high precision bits of which are presumably
          difficult to predict.
    
    (2) is impossible without CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y. But (1) is
    always possible. However, currently CONFIG_GCC_PLUGIN_LATENT_ENTROPY=n
    disables both (1) and (2), instead of just (2).
    
    This commit causes the CONFIG_GCC_PLUGIN_LATENT_ENTROPY=n case to still
    do (1) by passing NULL (len 0) to add_device_randomness() when add_latent_
    entropy() is called.
    
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: PaX Team <pageexec@freemail.hu>
    Cc: Emese Revfy <re.emese@gmail.com>
    Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c30e4cc30aeca519e82babfa1f05bfcf146b654b
Author: Sean Anderson <sean.anderson@seco.com>
Date:   Mon Oct 17 16:22:39 2022 -0400

    powerpc: dts: t208x: Mark MAC1 and MAC2 as 10G
    
    [ Upstream commit 36926a7d70c2d462fca1ed85bfee000d17fd8662 ]
    
    On the T208X SoCs, MAC1 and MAC2 support XGMII. Add some new MAC dtsi
    fragments, and mark the QMAN ports as 10G.
    
    Fixes: da414bb923d9 ("powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)")
    Signed-off-by: Sean Anderson <sean.anderson@seco.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5afca5df3dc73d3c400386121729ab1a5db2872
Author: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Date:   Wed Sep 28 23:36:51 2022 +0300

    wifi: rtl8xxxu: gen2: Turn on the rate control
    
    [ Upstream commit 791082ec0ab843e0be07c8ce3678e4c2afd2e33d ]
    
    Re-enable the function rtl8xxxu_gen2_report_connect.
    
    It informs the firmware when connecting to a network. This makes the
    firmware enable the rate control, which makes the upload faster.
    
    It also informs the firmware when disconnecting from a network. In the
    past this made reconnecting impossible because it was sending the
    auth on queue 0x7 (TXDESC_QUEUE_VO) instead of queue 0x12
    (TXDESC_QUEUE_MGNT):
    
    wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 1/3)
    wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 2/3)
    wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 3/3)
    wlp0s20f0u3: authentication with 90:55:de:__:__:__ timed out
    
    Probably the firmware disables the unnecessary TX queues when it
    knows it's disconnected.
    
    However, this was fixed in commit edd5747aa12e ("wifi: rtl8xxxu: Fix
    skb misuse in TX queue selection").
    
    Fixes: c59f13bbead4 ("rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting")
    Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/43200afc-0c65-ee72-48f8-231edd1df493@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>