σΠΙΣΟΛ ΙΪΝΕΞΕΞΙΚ Χ Linux 5.4.188

 
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: 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: 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>

 
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>

 
esp: Fix possible buffer overflow in ESP transformation [+ + +]
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Mon Mar 7 13:11:39 2022 +0100

    esp: Fix possible buffer overflow in ESP transformation
    
    commit ebe48d368e97d007bfeb76fcb065d6cfc4c96645 upstream.
    
    The maximum message size that can be send is bigger than
    the  maximum site that skb_page_frag_refill can allocate.
    So it is possible to write beyond the allocated buffer.
    
    Fix this by doing a fallback to COW in that case.
    
    v2:
    
    Avoid get get_order() costs as suggested by Linus Torvalds.
    
    Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
    Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
    Reported-by: valis <sec@valis.email>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Vaibhav Rustagi <vaibhavrustagi@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.4.188 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Mar 28 08:46:49 2022 +0200

    Linux 5.4.188
    
    Link: https://lore.kernel.org/r/20220325150418.585286754@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.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>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    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>

 
nfsd: cleanup nfsd_file_lru_dispose() [+ + +]
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Mon Jan 6 13:18:04 2020 -0500

    nfsd: cleanup nfsd_file_lru_dispose()
    
    commit 36ebbdb96b694dd9c6b25ad98f2bbd263d022b63 upstream.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Cc: Khazhy Kumykov <khazhy@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nfsd: Containerise filecache laundrette [+ + +]
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Mon Jan 6 13:18:05 2020 -0500

    nfsd: Containerise filecache laundrette
    
    commit 9542e6a643fc69d528dfb3303f145719c61d3050 upstream.
    
    Ensure that if the filecache laundrette gets stuck, it only affects
    the knfsd instances of one container.
    
    The notifier callbacks can be called from various contexts so avoid
    using synchonous filesystem operations that might deadlock.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Cc: Khazhy Kumykov <khazhy@google.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>

 
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>

 
thermal: int340x: fix memory leak in int3400_notify() [+ + +]
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date:   Wed Feb 23 08:20:24 2022 +0800

    thermal: int340x: fix memory leak in int3400_notify()
    
    commit 3abea10e6a8f0e7804ed4c124bea2d15aca977c8 upstream.
    
    It is easy to hit the below memory leaks in my TigerLake platform:
    
    unreferenced object 0xffff927c8b91dbc0 (size 32):
      comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
      hex dump (first 32 bytes):
        4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65  NAME=INT3400 The
        72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  rmal.kkkkkkkkkk.
      backtrace:
        [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0
        [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0
        [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70
        [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal]
        [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71
        [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30
        [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0
        [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0
        [<ffffffff9c2cb4dd>] kthread+0xfd/0x130
        [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30
    
    Fix it by calling kfree() accordingly.
    
    Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event")
    Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
    Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.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>