Linux 5.10.109

 
ACPI / x86: Work around broken XSDT on Advantech DAC-BJ01 board [+ + +]
Author: Mark Cilissen <mark@yotsuba.nl>
Date:   Mon Mar 7 04:16:58 2022 +0100

    ACPI / x86: Work around broken XSDT on Advantech DAC-BJ01 board
    
    commit e702196bf85778f2c5527ca47f33ef2e2fca8297 upstream.
    
    On this board the ACPI RSDP structure points to both a RSDT and an XSDT,
    but the XSDT points to a truncated FADT. This causes all sorts of trouble
    and usually a complete failure to boot after the following error occurs:
    
      ACPI Error: Unsupported address space: 0x20 (*/hwregs-*)
      ACPI Error: AE_SUPPORT, Unable to initialize fixed events (*/evevent-*)
      ACPI: Unable to start ACPI Interpreter
    
    This leaves the ACPI implementation in such a broken state that subsequent
    kernel subsystem initialisations go wrong, resulting in among others
    mismapped PCI memory, SATA and USB enumeration failures, and freezes.
    
    As this is an older embedded platform that will likely never see any BIOS
    updates to address this issue and its default shipping OS only complies to
    ACPI 1.0, work around this by forcing `acpi=rsdt`. This patch, applied on
    top of Linux 5.10.102, was confirmed on real hardware to fix the issue.
    
    Signed-off-by: Mark Cilissen <mark@yotsuba.nl>
    Cc: All applicable <stable@vger.kernel.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ACPI: battery: Add device HID and quirk for Microsoft Surface Go 3 [+ + +]
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Sun Feb 13 16:49:20 2022 +0100

    ACPI: battery: Add device HID and quirk for Microsoft Surface Go 3
    
    commit 7dacee0b9efc8bd061f097b1a8d4daa6591af0c6 upstream.
    
    For some reason, the Microsoft Surface Go 3 uses the standard ACPI
    interface for battery information, but does not use the standard PNP0C0A
    HID. Instead it uses MSHW0146 as identifier. Add that ID to the driver
    as this seems to work well.
    
    Additionally, the power state is not updated immediately after the AC
    has been (un-)plugged, so add the respective quirk for that.
    
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU [+ + +]
Author: Werner Sembach <wse@tuxedocomputers.com>
Date:   Tue Mar 15 20:02:28 2022 +0100

    ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU
    
    commit c844d22fe0c0b37dc809adbdde6ceb6462c43acf upstream.
    
    Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a working
    native and video interface. However the default detection mechanism first
    registers the video interface before unregistering it again and switching
    to the native interface during boot. This results in a dangling SBIOS
    request for backlight change for some reason, causing the backlight to
    switch to ~2% once per boot on the first power cord connect or disconnect
    event. Setting the native interface explicitly circumvents this buggy
    behaviour by avoiding the unregistering process.
    
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: cmipci: Restore aux vol on suspend/resume [+ + +]
Author: Jonathan Teh <jonathan.teh@outlook.com>
Date:   Sun Mar 13 19:56:17 2022 +0000

    ALSA: cmipci: Restore aux vol on suspend/resume
    
    commit c14231cc04337c2c2a937db084af342ce704dbde upstream.
    
    Save and restore CM_REG_AUX_VOL instead of register 0x24 twice on
    suspend/resume.
    
    Tested on CMI8738LX.
    
    Fixes: cb60e5f5b2b1 ("[ALSA] cmipci - Add PM support")
    Signed-off-by: Jonathan Teh <jonathan.teh@outlook.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/DBAPR04MB7366CB3EA9C8521C35C56E8B920E9@DBAPR04MB7366.eurprd04.prod.outlook.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc671 [+ + +]
Author: huangwenhui <huangwenhuia@uniontech.com>
Date:   Fri Mar 11 17:38:36 2022 +0800

    ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc671
    
    commit 882bd07f564f97fca6e42ce6ce627ce24ce1ef5a upstream.
    
    On a HP 288 Pro G8, the front mic could not be detected.In order to
    get it working, the pin configuration needs to be set correctly, and
    the ALC671_FIXUP_HP_HEADSET_MIC2 fixup needs to be applied.
    
    Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220311093836.20754-1-huangwenhuia@uniontech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for ASUS GA402 [+ + +]
Author: Jason Zheng <jasonzheng2004@gmail.com>
Date:   Sun Mar 13 04:22:16 2022 -0500

    ALSA: hda/realtek: Add quirk for ASUS GA402
    
    commit b7557267c233b55d8e8d7ba4c68cf944fe2ec02c upstream.
    
    ASUS GA402 requires a workaround to manage the routing of its 4 speakers
    like the other ASUS models. Add a corresponding quirk entry to fix it.
    
    Signed-off-by: Jason Zheng <jasonzheng2004@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220313092216.29858-1-jasonzheng2004@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for Clevo NP50PNJ [+ + +]
Author: Tim Crawford <tcrawford@system76.com>
Date:   Mon Mar 7 12:32:29 2022 -0700

    ALSA: hda/realtek: Add quirk for Clevo NP50PNJ
    
    commit 9cb727506704b5323998047789fc871e64a6aa14 upstream.
    
    Fixes headset detection on Clevo NP50PNJ.
    
    Signed-off-by: Tim Crawford <tcrawford@system76.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220307193229.5141-1-tcrawford@system76.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for Clevo NP70PNJ [+ + +]
Author: Tim Crawford <tcrawford@system76.com>
Date:   Fri Mar 4 10:08:40 2022 -0700

    ALSA: hda/realtek: Add quirk for Clevo NP70PNJ
    
    commit 0c20fce13e6e111463e3a15ce3cf6713fe518388 upstream.
    
    Fixes headset detection on Clevo NP70PNJ.
    
    Signed-off-by: Tim Crawford <tcrawford@system76.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220304170840.3351-1-tcrawford@system76.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: oss: Fix PCM OSS buffer allocation overflow [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Mar 18 09:20:36 2022 +0100

    ALSA: oss: Fix PCM OSS buffer allocation overflow
    
    commit efb6402c3c4a7c26d97c92d70186424097b6e366 upstream.
    
    We've got syzbot reports hitting INT_MAX overflow at vmalloc()
    allocation that is called from snd_pcm_plug_alloc().  Although we
    apply the restrictions to input parameters, it's based only on the
    hw_params of the underlying PCM device.  Since the PCM OSS layer
    allocates a temporary buffer for the data conversion, the size may
    become unexpectedly large when more channels or higher rates is given;
    in the reported case, it went over INT_MAX, hence it hits WARN_ON().
    
    This patch is an attempt to avoid such an overflow and an allocation
    for too large buffers.  First off, it adds the limit of 1MB as the
    upper bound for period bytes.  This must be large enough for all use
    cases, and we really don't want to handle a larger temporary buffer
    than this size.  The size check is performed at two places, where the
    original period bytes is calculated and where the plugin buffer size
    is calculated.
    
    In addition, the driver uses array_size() and array3_size() for
    multiplications to catch overflows for the converted period size and
    buffer bytes.
    
    Reported-by: syzbot+72732c532ac1454eeee9@syzkaller.appspotmail.com
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/00000000000085b1b305da5a66f3@google.com
    Link: https://lore.kernel.org/r/20220318082036.29699-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec [+ + +]
Author: Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
Date:   Tue Mar 22 21:06:54 2022 +0100

    ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec
    
    commit 17aaf0193392cb3451bf0ac75ba396ec4cbded6e upstream.
    
    Tests 72 and 78 for ALSA in kselftest fail due to reading
    inconsistent values from some devices on a VirtualBox
    Virtual Machine using the snd_intel8x0 driver for the AC'97
    Audio Controller device.
    Taking for example test number 72, this is what the test reports:
    "Surround Playback Volume.0 expected 1 but read 0, is_volatile 0"
    "Surround Playback Volume.1 expected 0 but read 1, is_volatile 0"
    These errors repeat for each value from 0 to 31.
    
    Taking a look at these error messages it is possible to notice
    that the written values are read back swapped.
    When the write is performed, these values are initially stored in
    an array used to sanity-check them and write them in the pcmreg
    array. To write them, the two one-byte values are packed together
    in a two-byte variable through bitwise operations: the first
    value is shifted left by one byte and the second value is stored in the
    right byte through a bitwise OR. When reading the values back,
    right shifts are performed to retrieve the previously stored
    bytes. These shifts are executed in the wrong order, thus
    reporting the values swapped as shown above.
    
    This patch fixes this mistake by reversing the read
    operations' order.
    
    Signed-off-by: Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
    Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Add stream lock during PCM reset ioctl operations [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 22 18:13:25 2022 +0100

    ALSA: pcm: Add stream lock during PCM reset ioctl operations
    
    commit 1f68915b2efd0d6bfd6e124aa63c94b3c69f127c upstream.
    
    snd_pcm_reset() is a non-atomic operation, and it's allowed to run
    during the PCM stream running.  It implies that the manipulation of
    hw_ptr and other parameters might be racy.
    
    This patch adds the PCM stream lock at appropriate places in
    snd_pcm_*_reset() actions for covering that.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20220322171325.4355-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Fix races among concurrent hw_params and hw_free calls [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 22 18:07:17 2022 +0100

    ALSA: pcm: Fix races among concurrent hw_params and hw_free calls
    
    commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream.
    
    Currently we have neither proper check nor protection against the
    concurrent calls of PCM hw_params and hw_free ioctls, which may result
    in a UAF.  Since the existing PCM stream lock can't be used for
    protecting the whole ioctl operations, we need a new mutex to protect
    those racy calls.
    
    This patch introduced a new mutex, runtime->buffer_mutex, and applies
    it to both hw_params and hw_free ioctl code paths.  Along with it, the
    both functions are slightly modified (the mmap_count check is moved
    into the state-check block) for code simplicity.
    
    Reported-by: Hu Jiahui <kirin.say@gmail.com>
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Fix races among concurrent prealloc proc writes [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 22 18:07:20 2022 +0100

    ALSA: pcm: Fix races among concurrent prealloc proc writes
    
    commit 69534c48ba8ce552ce383b3dfdb271ffe51820c3 upstream.
    
    We have no protection against concurrent PCM buffer preallocation
    changes via proc files, and it may potentially lead to UAF or some
    weird problem.  This patch applies the PCM open_mutex to the proc
    write operation for avoiding the racy proc writes and the PCM stream
    open (and further operations).
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20220322170720.3529-5-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 22 18:07:19 2022 +0100

    ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls
    
    commit 3c3201f8c7bb77eb53b08a3ca8d9a4ddc500b4c0 upstream.
    
    Like the previous fixes to hw_params and hw_free ioctl races, we need
    to paper over the concurrent prepare ioctl calls against hw_params and
    hw_free, too.
    
    This patch implements the locking with the existing
    runtime->buffer_mutex for prepare ioctls.  Unlike the previous case
    for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is
    performed to the linked streams, hence the lock can't be applied
    simply on the top.  For tracking the lock in each linked substream, we
    modify snd_pcm_action_group() slightly and apply the buffer_mutex for
    the case stream_lock=false (formerly there was no lock applied)
    there.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20220322170720.3529-4-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Fix races among concurrent read/write and buffer changes [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 22 18:07:18 2022 +0100

    ALSA: pcm: Fix races among concurrent read/write and buffer changes
    
    commit dca947d4d26dbf925a64a6cfb2ddbc035e831a3d upstream.
    
    In the current PCM design, the read/write syscalls (as well as the
    equivalent ioctls) are allowed before the PCM stream is running, that
    is, at PCM PREPARED state.  Meanwhile, we also allow to re-issue
    hw_params and hw_free ioctl calls at the PREPARED state that may
    change or free the buffers, too.  The problem is that there is no
    protection against those mix-ups.
    
    This patch applies the previously introduced runtime->buffer_mutex to
    the read/write operations so that the concurrent hw_params or hw_free
    call can no longer interfere during the operation.  The mutex is
    unlocked before scheduling, so we don't take it too long.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20220322170720.3529-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: add mapping for new Corsair Virtuoso SE [+ + +]
Author: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com>
Date:   Fri Mar 4 22:23:02 2022 +0100

    ALSA: usb-audio: add mapping for new Corsair Virtuoso SE
    
    commit cd94df1795418056a19ff4cb44eadfc18ac99a57 upstream.
    
    New device id for Corsair Virtuoso SE RGB Wireless that currently is not
    in the mixer_map. This entry in the mixer_map is necessary in order to
    label its mixer appropriately and allow userspace to pick the correct
    volume controls. For instance, my own Corsair Virtuoso SE RGB Wireless
    headset has this new ID and consequently, the sidetone and volume are not
     working correctly without this change.
    > sudo lsusb -v | grep -i corsair
    Bus 007 Device 011: ID 1b1c:0a40 Corsair CORSAIR VIRTUOSO SE Wireless Gam
      idVendor           0x1b1c Corsair
      iManufacturer           1 Corsair
      iProduct                2 CORSAIR VIRTUOSO SE Wireless Gaming Headset
    
    Signed-off-by: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220304212303.195949-1-reza.jahanbakhshi@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USB [+ + +]
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Fri Mar 11 21:14:00 2022 +0100

    ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USB
    
    commit 0f306cca42fe879694fb5e2382748c43dc9e0196 upstream.
    
    For the RODE NT-USB the lowest Playback mixer volume setting mutes the
    audio output. But it is not reported as such causing e.g. PulseAudio to
    accidentally mute the device when selecting a low volume.
    
    Fix this by applying the existing quirk for this kind of issue when the
    device is detected.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220311201400.235892-1-lars@metafoo.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 15 17:41:58 2022 +0100

    ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call
    
    commit 455c5653f50e10b4f460ef24e99f0044fbe3401c upstream.
    
    This is essentially a revert of the commit dc865fb9e7c2 ("ASoC: sti:
    Use snd_pcm_stop_xrun() helper"), which converted the manual
    snd_pcm_stop() calls with snd_pcm_stop_xrun().
    
    The commit above introduced a deadlock as snd_pcm_stop_xrun() itself
    takes the PCM stream lock while the caller already holds it.  Since
    the conversion was done only for consistency reason and the open-call
    with snd_pcm_stop() to the XRUN state is a correct usage, let's revert
    the commit back as the fix.
    
    Fixes: dc865fb9e7c2 ("ASoC: sti: Use snd_pcm_stop_xrun() helper")
    Reported-by: Daniel Palmer <daniel@0x0f.com>
    Cc: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220315091319.3351522-1-daniel@0x0f.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Link: https://lore.kernel.org/r/20220315164158.19804-1-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cgroup-v1: Correct privileges check in release_agent writes [+ + +]
Author: Michal Koutný <mkoutny@suse.com>
Date:   Thu Feb 17 17:11:28 2022 +0100

    cgroup-v1: Correct privileges check in release_agent writes
    
    commit 467a726b754f474936980da793b4ff2ec3e382a7 upstream.
    
    The idea is to check: a) the owning user_ns of cgroup_ns, b)
    capabilities in init_user_ns.
    
    The commit 24f600856418 ("cgroup-v1: Require capabilities to set
    release_agent") got this wrong in the write handler of release_agent
    since it checked user_ns of the opener (may be different from the owning
    user_ns of cgroup_ns).
    Secondly, to avoid possibly confused deputy, the capability of the
    opener must be checked.
    
    Fixes: 24f600856418 ("cgroup-v1: Require capabilities to set release_agent")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/stable/20220216121142.GB30035@blackbody.suse.cz/
    Signed-off-by: Michal Koutný <mkoutny@suse.com>
    Reviewed-by: Masami Ichikawa(CIP) <masami.ichikawa@cybertrust.co.jp>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jan 6 11:02:29 2022 -1000

    cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv
    
    commit 0d2b5955b36250a9428c832664f2079cbf723bec upstream.
    
    of->priv is currently used by each interface file implementation to store
    private information. This patch collects the current two private data usages
    into struct cgroup_file_ctx which is allocated and freed by the common path.
    This allows generic private data which applies to multiple files, which will
    be used to in the following patch.
    
    Note that cgroup_procs iterator is now embedded as procs.iter in the new
    cgroup_file_ctx so that it doesn't need to be allocated and freed
    separately.
    
    v2: union dropped from cgroup_file_ctx and the procs iterator is embedded in
        cgroup_file_ctx as suggested by Linus.
    
    v3: Michal pointed out that cgroup1's procs pidlist uses of->priv too.
        Converted. Didn't change to embedded allocation as cgroup1 pidlists get
        stored for caching.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Reviewed-by: Michal Koutný <mkoutny@suse.com>
    [mkoutny: v5.10: modify cgroup.pressure handlers, adjust context]
    Signed-off-by: Michal Koutný <mkoutny@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cgroup: Use open-time cgroup namespace for process migration perm checks [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jan 6 11:02:29 2022 -1000

    cgroup: Use open-time cgroup namespace for process migration perm checks
    
    commit e57457641613fef0d147ede8bd6a3047df588b95 upstream.
    
    cgroup process migration permission checks are performed at write time as
    whether a given operation is allowed or not is dependent on the content of
    the write - the PID. This currently uses current's cgroup namespace which is
    a potential security weakness as it may allow scenarios where a less
    privileged process tricks a more privileged one into writing into a fd that
    it created.
    
    This patch makes cgroup remember the cgroup namespace at the time of open
    and uses it for migration permission checks instad of current's. Note that
    this only applies to cgroup2 as cgroup1 doesn't have namespace support.
    
    This also fixes a use-after-free bug on cgroupns reported in
    
     https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
    
    Note that backporting this fix also requires the preceding patch.
    
    Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Cc: Michal Koutný <mkoutny@suse.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Reviewed-by: Michal Koutný <mkoutny@suse.com>
    Reported-by: syzbot+50f5cf33a284ce738b62@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
    Fixes: 5136f6365ce3 ("cgroup: implement "nsdelegate" mount option")
    Signed-off-by: Tejun Heo <tj@kernel.org>
    [mkoutny: v5.10: duplicate ns check in procs/threads write handler, adjust context]
    Signed-off-by: Michal Koutný <mkoutny@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
crypto: qat - disable registration of algorithms [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Fri Mar 4 17:54:47 2022 +0000

    crypto: qat - disable registration of algorithms
    
    commit 8893d27ffcaf6ec6267038a177cb87bcde4dd3de upstream.
    
    The implementations of aead and skcipher in the QAT driver do not
    support properly requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set.
    If the HW queue is full, the driver returns -EBUSY but does not enqueue
    the request.
    This can result in applications like dm-crypt waiting indefinitely for a
    completion of a request that was never submitted to the hardware.
    
    To avoid this problem, disable the registration of all crypto algorithms
    in the QAT driver by setting the number of crypto instances to 0 at
    configuration time.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drivers: net: xgene: Fix regression in CRC stripping [+ + +]
Author: Stephane Graber <stgraber@ubuntu.com>
Date:   Tue Mar 22 18:42:06 2022 -0400

    drivers: net: xgene: Fix regression in CRC stripping
    
    commit e9e6faeafaa00da1851bcf47912b0f1acae666b4 upstream.
    
    All packets on ingress (except for jumbo) are terminated with a 4-bytes
    CRC checksum. It's the responsability of the driver to strip those 4
    bytes. Unfortunately a change dating back to March 2017 re-shuffled some
    code and made the CRC stripping code effectively dead.
    
    This change re-orders that part a bit such that the datalen is
    immediately altered if needed.
    
    Fixes: 4902a92270fb ("drivers: net: xgene: Add workaround for errata 10GE_8/ENET_11")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stephane Graber <stgraber@ubuntu.com>
    Tested-by: Stephane Graber <stgraber@ubuntu.com>
    Link: https://lore.kernel.org/r/20220322224205.752795-1-stgraber@ubuntu.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
exfat: avoid incorrectly releasing for root inode [+ + +]
Author: Chen Li <chenli@uniontech.com>
Date:   Wed Jun 9 11:48:55 2021 +0800

    exfat: avoid incorrectly releasing for root inode
    
    commit 839a534f1e853f1aec100d06040c0037b89c2dc3 upstream.
    
    In d_make_root, when we fail to allocate dentry for root inode,
    we will iput root inode and returned value is NULL in this function.
    
    So we do not need to release this inode again at d_make_root's caller.
    
    Signed-off-by: Chen Li <chenli@uniontech.com>
    Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
    Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.10.109 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Mar 28 09:57:11 2022 +0200

    Linux 5.10.109
    
    Link: https://lore.kernel.org/r/20220325150419.757836392@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
llc: fix netdevice reference leaks in llc_ui_bind() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 22 17:41:47 2022 -0700

    llc: fix netdevice reference leaks in llc_ui_bind()
    
    commit 764f4eb6846f5475f1244767d24d25dd86528a4a upstream.
    
    Whenever llc_ui_bind() and/or llc_ui_autobind()
    took a reference on a netdevice but subsequently fail,
    they must properly release their reference
    or risk the infamous message from unregister_netdevice()
    at device dismantle.
    
    unregister_netdevice: waiting for eth0 to become free. Usage count = 3
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: 赵子轩 <beraphin@gmail.com>
    Reported-by: Stoyan Manolov <smanolov@suse.de>
    Link: https://lore.kernel.org/r/20220323004147.1990845-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

llc: only change llc->dev when bind() succeeds [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 24 20:58:27 2022 -0700

    llc: only change llc->dev when bind() succeeds
    
    commit 2d327a79ee176930dc72c131a970c891d367c1dc upstream.
    
    My latest patch, attempting to fix the refcount leak in a minimal
    way turned out to add a new bug.
    
    Whenever the bind operation fails before we attempt to grab
    a reference count on a device, we might release the device refcount
    of a prior successful bind() operation.
    
    syzbot was not happy about this [1].
    
    Note to stable teams:
    
    Make sure commit b37a46683739 ("netdevice: add the case if dev is NULL")
    is already present in your trees.
    
    [1]
    general protection fault, probably for non-canonical address 0xdffffc0000000070: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
    CPU: 1 PID: 3590 Comm: syz-executor361 Tainted: G        W         5.17.0-syzkaller-04796-g169e77764adc #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:llc_ui_connect+0x400/0xcb0 net/llc/af_llc.c:500
    Code: 80 3c 02 00 0f 85 fc 07 00 00 4c 8b a5 38 05 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 80 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a9 07 00 00 49 8b b4 24 80 03 00 00 4c 89 f2 48
    RSP: 0018:ffffc900038cfcc0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: ffff8880756eb600 RCX: 0000000000000000
    RDX: 0000000000000070 RSI: ffffc900038cfe3e RDI: 0000000000000380
    RBP: ffff888015ee5000 R08: 0000000000000001 R09: ffff888015ee5535
    R10: ffffed1002bdcaa6 R11: 0000000000000000 R12: 0000000000000000
    R13: ffffc900038cfe37 R14: ffffc900038cfe38 R15: ffff888015ee5012
    FS:  0000555555acd300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000280 CR3: 0000000077db6000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     __sys_connect_file+0x155/0x1a0 net/socket.c:1900
     __sys_connect+0x161/0x190 net/socket.c:1917
     __do_sys_connect net/socket.c:1927 [inline]
     __se_sys_connect net/socket.c:1924 [inline]
     __x64_sys_connect+0x6f/0xb0 net/socket.c:1924
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f016acb90b9
    Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffd417947f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f016acb90b9
    RDX: 0000000000000010 RSI: 0000000020000140 RDI: 0000000000000003
    RBP: 00007f016ac7d0a0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f016ac7d130
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:llc_ui_connect+0x400/0xcb0 net/llc/af_llc.c:500
    
    Fixes: 764f4eb6846f ("llc: fix netdevice reference leaks in llc_ui_bind()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: 赵子轩 <beraphin@gmail.com>
    Cc: Stoyan Manolov <smanolov@suse.de>
    Link: https://lore.kernel.org/r/20220325035827.360418-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mac80211: fix potential double free on mesh join [+ + +]
Author: Linus Lüssing <ll@simonwunderlich.de>
Date:   Thu Mar 10 19:35:13 2022 +0100

    mac80211: fix potential double free on mesh join
    
    commit 4a2d4496e15ea5bb5c8e83b94ca8ca7fb045e7d3 upstream.
    
    While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving
    mesh") fixed a memory leak on mesh leave / teardown it introduced a
    potential memory corruption caused by a double free when rejoining the
    mesh:
    
      ieee80211_leave_mesh()
      -> kfree(sdata->u.mesh.ie);
      ...
      ieee80211_join_mesh()
      -> copy_mesh_setup()
         -> old_ie = ifmsh->ie;
         -> kfree(old_ie);
    
    This double free / kernel panics can be reproduced by using wpa_supplicant
    with an encrypted mesh (if set up without encryption via "iw" then
    ifmsh->ie is always NULL, which avoids this issue). And then calling:
    
      $ iw dev mesh0 mesh leave
      $ iw dev mesh0 mesh join my-mesh
    
    Note that typically these commands are not used / working when using
    wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going
    through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join
    where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of
    default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids
    the memory corruption, too.
    
    The issue was first observed in an application which was not using
    wpa_supplicant but "Senf" instead, which implements its own calls to
    nl80211.
    
    Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh
    join function and leaving it solely up to the mesh leave to free the
    mesh IE.
    
    Cc: stable@vger.kernel.org
    Fixes: 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh")
    Reported-by: Matthias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
    Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
    Tested-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
    Link: https://lore.kernel.org/r/20220310183513.28589-1-linus.luessing@c0d3.blue
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nds32: fix access_ok() checks in get/put_user [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 14 15:48:14 2022 +0100

    nds32: fix access_ok() checks in get/put_user
    
    commit 8926d88ced46700bf6117ceaf391480b943ea9f4 upstream.
    
    The get_user()/put_user() functions are meant to check for
    access_ok(), while the __get_user()/__put_user() functions
    don't.
    
    This broke in 4.19 for nds32, when it gained an extraneous
    check in __get_user(), but lost the check it needs in
    __put_user().
    
    Fixes: 487913ab18c2 ("nds32: Extract the checking and getting pointer to a macro")
    Cc: stable@vger.kernel.org @ v4.19+
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: ipv6: fix skb_over_panic in __ip6_append_data [+ + +]
Author: Tadeusz Struk <tadeusz.struk@linaro.org>
Date:   Thu Mar 10 15:25:38 2022 -0800

    net: ipv6: fix skb_over_panic in __ip6_append_data
    
    commit 5e34af4142ffe68f01c8a9acae83300f8911e20c upstream.
    
    Syzbot found a kernel bug in the ipv6 stack:
    LINK: https://syzkaller.appspot.com/bug?id=205d6f11d72329ab8d62a610c44c5e7e25415580
    The reproducer triggers it by sending a crafted message via sendmmsg()
    call, which triggers skb_over_panic, and crashes the kernel:
    
    skbuff: skb_over_panic: text:ffffffff84647fb4 len:65575 put:65575
    head:ffff888109ff0000 data:ffff888109ff0088 tail:0x100af end:0xfec0
    dev:<NULL>
    
    Update the check that prevents an invalid packet with MTU equal
    to the fregment header size to eat up all the space for payload.
    
    The reproducer can be found here:
    LINK: https://syzkaller.appspot.com/text?tag=ReproC&x=1648c83fb00000
    
    Reported-by: syzbot+e223cf47ec8ae183f2a0@syzkaller.appspotmail.com
    Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20220310232538.1044947-1-tadeusz.struk@linaro.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netfilter: nf_tables: initialize registers in nft_do_chain() [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Mar 17 12:04:42 2022 +0100

    netfilter: nf_tables: initialize registers in nft_do_chain()
    
    commit 4c905f6740a365464e91467aa50916555b28213d upstream.
    
    Initialize registers to avoid stack leak into userspace.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION [+ + +]
Author: Jordy Zomer <jordy@pwning.systems>
Date:   Tue Jan 11 17:44:51 2022 +0100

    nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION
    
    commit 4fbcc1a4cb20fe26ad0225679c536c80f1648221 upstream.
    
    It appears that there are some buffer overflows in EVT_TRANSACTION.
    This happens because the length parameters that are passed to memcpy
    come directly from skb->data and are not guarded in any way.
    
    Signed-off-by: Jordy Zomer <jordy@pwning.systems>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Denis Efremov <denis.e.efremov@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
rcu: Don't deboost before reporting expedited quiescent state [+ + +]
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Fri Jan 21 12:40:08 2022 -0800

    rcu: Don't deboost before reporting expedited quiescent state
    
    commit 10c535787436d62ea28156a4b91365fd89b5a432 upstream.
    
    Currently rcu_preempt_deferred_qs_irqrestore() releases rnp->boost_mtx
    before reporting the expedited quiescent state.  Under heavy real-time
    load, this can result in this function being preempted before the
    quiescent state is reported, which can in turn prevent the expedited grace
    period from completing.  Tim Murray reports that the resulting expedited
    grace periods can take hundreds of milliseconds and even more than one
    second, when they should normally complete in less than a millisecond.
    
    This was fine given that there were no particular response-time
    constraints for synchronize_rcu_expedited(), as it was designed
    for throughput rather than latency.  However, some users now need
    sub-100-millisecond response-time constratints.
    
    This patch therefore follows Neeraj's suggestion (seconded by Tim and
    by Uladzislau Rezki) of simply reversing the two operations.
    
    Reported-by: Tim Murray <timmurray@google.com>
    Reported-by: Joel Fernandes <joelaf@google.com>
    Reported-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
    Reviewed-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
    Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Tested-by: Tim Murray <timmurray@google.com>
    Cc: Todd Kjos <tkjos@google.com>
    Cc: Sandeep Patil <sspatil@google.com>
    Cc: <stable@vger.kernel.org> # 5.4.x
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "ath: add support for special 0x0 regulatory domain" [+ + +]
Author: Brian Norris <briannorris@chromium.org>
Date:   Fri Feb 25 11:44:32 2022 +0200

    Revert "ath: add support for special 0x0 regulatory domain"
    
    commit 1ec7ed5163c70a0d040150d2279f932c7e7c143f upstream.
    
    This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
    
    Users are reporting regressions in regulatory domain detection and
    channel availability.
    
    The problem this was trying to resolve was fixed in firmware anyway:
    
        QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042
        https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552
    
    Link: https://bbs.archlinux.org/viewtopic.php?id=254535
    Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html
    Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html
    Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/
    Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
    Cc: <stable@vger.kernel.org>
    Cc: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20200527165718.129307-1-briannorris@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
staging: fbtft: fb_st7789v: reset display before initialization [+ + +]
Author: Oliver Graute <oliver.graute@kococonnector.com>
Date:   Thu Feb 10 09:53:22 2022 +0100

    staging: fbtft: fb_st7789v: reset display before initialization
    
    commit b6821b0d9b56386d2bf14806f90ec401468c799f upstream.
    
    In rare cases the display is flipped or mirrored. This was observed more
    often in a low temperature environment. A clean reset on init_display()
    should help to get registers in a sane state.
    
    Fixes: ef8f317795da (staging: fbtft: use init function instead of init sequence)
    Cc: stable@vger.kernel.org
    Signed-off-by: Oliver Graute <oliver.graute@kococonnector.com>
    Link: https://lore.kernel.org/r/20220210085322.15676-1-oliver.graute@kococonnector.com
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tpm: Fix error handling in async work [+ + +]
Author: Tadeusz Struk <tstruk@gmail.com>
Date:   Sat Jan 15 17:26:26 2022 -0800

    tpm: Fix error handling in async work
    
    commit 2e8e4c8f6673247e22efc7985ce5497accd16f88 upstream.
    
    When an invalid (non existing) handle is used in a TPM command,
    that uses the resource manager interface (/dev/tpmrm0) the resource
    manager tries to load it from its internal cache, but fails and
    the tpm_dev_transmit returns an -EINVAL error to the caller.
    The existing async handler doesn't handle these error cases
    currently and the condition in the poll handler never returns
    mask with EPOLLIN set.
    The result is that the poll call blocks and the application gets stuck
    until the user_read_timer wakes it up after 120 sec.
    Change the tpm_dev_async_work function to handle error conditions
    returned from tpm_dev_transmit they are also reflected in the poll mask
    and a correct error code could passed back to the caller.
    
    Cc: Jarkko Sakkinen <jarkko@kernel.org>
    Cc: Jason Gunthorpe <jgg@ziepe.ca>
    Cc: <linux-integrity@vger.kernel.org>
    Cc: <stable@vger.kernel.org>
    Cc: <linux-kernel@vger.kernel.org>
    
    Fixes: 9e1b74a63f77 ("tpm: add support for nonblocking operation")
    Tested-by: Jarkko Sakkinen<jarkko@kernel.org>
    Signed-off-by: Tadeusz Struk <tstruk@gmail.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tpm: use try_get_ops() in tpm-space.c [+ + +]
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Mon Mar 7 15:58:03 2022 -0500

    tpm: use try_get_ops() in tpm-space.c
    
    commit fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9 upstream.
    
    As part of the series conversion to remove nested TPM operations:
    
    https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/
    
    exposure of the chip->tpm_mutex was removed from much of the upper
    level code.  In this conversion, tpm2_del_space() was missed.  This
    didn't matter much because it's usually called closely after a
    converted operation, so there's only a very tiny race window where the
    chip can be removed before the space flushing is done which causes a
    NULL deref on the mutex.  However, there are reports of this window
    being hit in practice, so fix this by converting tpm2_del_space() to
    use tpm_try_get_ops(), which performs all the teardown checks before
    acquring the mutex.
    
    Cc: stable@vger.kernel.org # 5.4.x
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wcn36xx: Differentiate wcn3660 from wcn3620 [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Tue Jan 25 00:40:46 2022 +0000

    wcn36xx: Differentiate wcn3660 from wcn3620
    
    commit 98d504a82cc75840bec8e3c6ae0e4f411921962b upstream.
    
    The spread of capability between the three WiFi silicon parts wcn36xx
    supports is:
    
    wcn3620 - 802.11 a/b/g
    wcn3660 - 802.11 a/b/g/n
    wcn3680 - 802.11 a/b/g/n/ac
    
    We currently treat wcn3660 as wcn3620 thus limiting it to 2GHz channels.
    Fix this regression by ensuring we differentiate between all three parts.
    
    Fixes: 8490987bdb9a ("wcn36xx: Hook and identify RF_IRIS_WCN3680")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20220125004046.4058284-1-bryan.odonoghue@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>