Список изменений в Linux 5.15.16

 
9p: only copy valid iattrs in 9P2000.L setattr implementation [+ + +]
Author: Christian Brauner <christian.brauner@ubuntu.com>
Date:   Mon Nov 29 12:44:34 2021 +0100

    9p: only copy valid iattrs in 9P2000.L setattr implementation
    
    commit 3cb6ee991496b67ee284c6895a0ba007e2d7bac3 upstream.
    
    The 9P2000.L setattr method v9fs_vfs_setattr_dotl() copies struct iattr
    values without checking whether they are valid causing unitialized
    values to be copied. The 9P2000 setattr method v9fs_vfs_setattr() method
    gets this right. Check whether struct iattr fields are valid first
    before copying in v9fs_vfs_setattr_dotl() too and make sure that all
    other fields are set to 0 apart from {g,u}id which should be set to
    INVALID_{G,U}ID. This ensure that they can be safely sent over the wire
    or printed for debugging later on.
    
    Link: https://lkml.kernel.org/r/20211129114434.3637938-1-brauner@kernel.org
    Link: https://lkml.kernel.org/r/000000000000a0d53f05d1c72a4c%40google.com
    Cc: Eric Van Hensbergen <ericvh@gmail.com>
    Cc: Latchesar Ionkov <lucho@ionkov.net>
    Cc: Dominique Martinet <asmadeus@codewreck.org>
    Cc: stable@kernel.org
    Cc: v9fs-developer@lists.sourceforge.net
    Reported-by: syzbot+dfac92a50024b54acaa4@syzkaller.appspotmail.com
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
    [Dominique: do not set a/mtime with just ATTR_A/MTIME as discussed]
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master after reboot from Windows [+ + +]
Author: Christian Lachner <gladiac@gmail.com>
Date:   Mon Jan 3 15:05:17 2022 +0100

    ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master after reboot from Windows
    
    commit c1933008679586b20437280463110c967d66f865 upstream.
    
    This patch addresses an issue where after rebooting from Windows into Linux
    there would be no audio output.
    
    It turns out that the Realtek Audio driver on Windows changes some coeffs
    which are not being reset/reinitialized when rebooting the machine. As a
    result, there is no audio output until these coeffs are being reset to
    their initial state. This patch takes care of that by setting known-good
    (initial) values to the coeffs.
    
    We initially relied upon alc1220_fixup_clevo_p950() to fix some pins in the
    connection list. However, it also sets coef 0x7 which does not need to be
    touched. Furthermore, to prevent mixing device-specific quirks I introduced
    a new alc1220_fixup_gb_x570() which is heavily based on
    alc1220_fixup_clevo_p950() but does not set coeff 0x7 and fixes the coeffs
    that are actually needed instead.
    
    This new alc1220_fixup_gb_x570() is believed to also work for other boards,
    like the Gigabyte X570 Aorus Extreme and the newer Gigabyte Aorus X570S
    Master. However, as there is no way for me to test these I initially only
    enable this new behaviour for the mainboard I have which is the Gigabyte
    X570(non-S) Aorus Master.
    
    I tested this patch on the 5.15 branch as well as on master and it is
    working well for me.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275
    Signed-off-by: Christian Lachner <gladiac@gmail.com>
    Fixes: 0d45e86d2267d ("ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220103140517.30273-2-gladiac@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 Legion Y9000X 2020 [+ + +]
Author: Baole Fang <fbl718@163.com>
Date:   Wed Jan 5 22:08:54 2022 +0800

    ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
    
    commit 8f4c90427a8f0ca0fcdd89d8966fcdab35fb2d4c upstream.
    
    Legion Y9000X 2020 has a speaker, but the speaker doesn't work.
    This can be fixed by applying alc285_fixup_ideapad_s740_coef
    to fix the speaker's coefficients.
    Besides, to support the transition between the speaker and the headphone,
    alc287_fixup_legion_15imhg05_speakers needs to be run.
    
    Signed-off-by: Baole Fang <fbl718@163.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220105140856.4855-1-fbl718@163.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add speaker fixup for some Yoga 15ITL5 devices [+ + +]
Author: Arie Geiger <arsgeiger@gmail.com>
Date:   Thu Dec 23 15:28:57 2021 -0800

    ALSA: hda/realtek: Add speaker fixup for some Yoga 15ITL5 devices
    
    commit 6dc86976220cc904e87ee58e4be19dd90d6a36d5 upstream.
    
    This patch adds another possible subsystem ID for the ALC287 used by
    the Lenovo Yoga 15ITL5.
    It uses the same initalization as the others.
    This patch has been tested and works for my device.
    
    Signed-off-by: Arie Geiger <arsgeiger@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211223232857.30741-1-arsgeiger@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Re-order quirk entries for Lenovo [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 5 17:03:21 2022 +0100

    ALSA: hda/realtek: Re-order quirk entries for Lenovo
    
    commit 2aac550da3257ab46e8c7944365eb4a79ccbb3a1 upstream.
    
    The recent few quirk entries for Lenovo haven't been put in the right
    order.  Let's arrange the table again.
    
    Fixes: ad7cc2d41b7a ("ALSA: hda/realtek: Quirks to enable speaker output...")
    Fixes: 6dc86976220c ("ALSA: hda/realtek: Add speaker fixup for some Yoga 15ITL5 devices")
    Fixes: 8f4c90427a8f ("ALSA: hda/realtek: Add quirk for Legion Y9000X 2020")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Use ALC285_FIXUP_HP_GPIO_LED on another HP laptop [+ + +]
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Dec 24 11:50:13 2021 +0800

    ALSA: hda/realtek: Use ALC285_FIXUP_HP_GPIO_LED on another HP laptop
    
    commit 08977fe8cfb7d9fe9337470eec4843081cf3a76d upstream.
    
    The audio mute and mic mute LEDs don't work, so use the quirk to make
    them work.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211224035015.310068-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/tegra: Fix Tegra194 HDA reset failure [+ + +]
Author: Sameer Pujar <spujar@nvidia.com>
Date:   Thu Dec 23 17:23:49 2021 +0530

    ALSA: hda/tegra: Fix Tegra194 HDA reset failure
    
    commit d278dc9151a034674b31ffeda24cdfb0073570f3 upstream.
    
    HDA regression is recently reported on Tegra194 based platforms.
    This happens because "hda2codec_2x" reset does not really exist
    in Tegra194 and it causes probe failure. All the HDA based audio
    tests fail at the moment. This underlying issue is exposed by
    commit c045ceb5a145 ("reset: tegra-bpmp: Handle errors in BPMP
    response") which now checks return code of BPMP command response.
    Fix this issue by skipping unavailable reset on Tegra194.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/1640260431-11613-2-git-send-email-spujar@nvidia.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: ALC287: Add Lenovo IdeaPad Slim 9i 14ITL5 speaker quirk [+ + +]
Author: Bart Kroon <bart@tarmack.eu>
Date:   Mon Dec 13 19:20:43 2021 +0100

    ALSA: hda: ALC287: Add Lenovo IdeaPad Slim 9i 14ITL5 speaker quirk
    
    commit b81e9e5c723de936652653241d3dc4f33ae05e8c upstream.
    
    The speaker fixup that is used for the Yoga 7 14ITL5 also applies to
    the IdeaPad Slim 9i 14ITL5. The attached patch applies the quirk to
    initialise the amplifier on the IdeaPad Slim 9i as well.
    
    This is validated to work on my laptop.
    
    [ corrected the quirk entry position by tiwai ]
    
    Signed-off-by: Bart Kroon <bart@tarmack.eu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/JAG24R.7NLJGWBF4G8U@tarmack.eu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
devtmpfs regression fix: reconfigure on each mount [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Mon Jan 17 09:07:26 2022 +1100

    devtmpfs regression fix: reconfigure on each mount
    
    commit a6097180d884ddab769fb25588ea8598589c218c upstream.
    
    Prior to Linux v5.4 devtmpfs used mount_single() which treats the given
    mount options as "remount" options, so it updates the configuration of
    the single super_block on each mount.
    
    Since that was changed, the mount options used for devtmpfs are ignored.
    This is a regression which affect systemd - which mounts devtmpfs with
    "-o mode=755,size=4m,nr_inodes=1m".
    
    This patch restores the "remount" effect by calling reconfigure_single()
    
    Fixes: d401727ea0d7 ("devtmpfs: don't mix {ramfs,shmem}_fill_super() with mount_single()")
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
drm/amd/display: explicitly set is_dsc_supported to false before use [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Jan 5 12:48:16 2022 -0600

    drm/amd/display: explicitly set is_dsc_supported to false before use
    
    commit 63ad5371cd1e379519395c49a4b6a652c36c98e5 upstream.
    
    When UBSAN is enabled a case is shown on unplugging the display that
    this variable hasn't been initialized by `update_dsc_caps`, presumably
    when the display was unplugged it wasn't copied from the DPCD.
    
    Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1956497
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firmware: qemu_fw_cfg: fix kobject leak in probe error path [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Dec 1 14:25:26 2021 +0100

    firmware: qemu_fw_cfg: fix kobject leak in probe error path
    
    commit 47a1db8e797da01a1309bf42e0c0d771d4e4d4f3 upstream.
    
    An initialised kobject must be freed using kobject_put() to avoid
    leaking associated resources (e.g. the object name).
    
    Commit fe3c60684377 ("firmware: Fix a reference count leak.") "fixed"
    the leak in the first error path of the file registration helper but
    left the second one unchanged. This "fix" would however result in a NULL
    pointer dereference due to the release function also removing the never
    added entry from the fw_cfg_entry_cache list. This has now been
    addressed.
    
    Fix the remaining kobject leak by restoring the common error path and
    adding the missing kobject_put().
    
    Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
    Cc: stable@vger.kernel.org      # 4.6
    Cc: Gabriel Somlo <somlo@cmu.edu>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211201132528.30025-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware: qemu_fw_cfg: fix NULL-pointer deref on duplicate entries [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Dec 1 14:25:25 2021 +0100

    firmware: qemu_fw_cfg: fix NULL-pointer deref on duplicate entries
    
    commit d3e305592d69e21e36b76d24ca3c01971a2d09be upstream.
    
    Commit fe3c60684377 ("firmware: Fix a reference count leak.") "fixed"
    a kobject leak in the file registration helper by properly calling
    kobject_put() for the entry in case registration of the object fails
    (e.g. due to a name collision).
    
    This would however result in a NULL pointer dereference when the
    release function tries to remove the never added entry from the
    fw_cfg_entry_cache list.
    
    Fix this by moving the list-removal out of the release function.
    
    Note that the offending commit was one of the benign looking umn.edu
    fixes which was reviewed but not reverted. [1][2]
    
    [1] https://lore.kernel.org/r/202105051005.49BFABCE@keescook
    [2] https://lore.kernel.org/all/YIg7ZOZvS3a8LjSv@kroah.com
    
    Fixes: fe3c60684377 ("firmware: Fix a reference count leak.")
    Cc: stable@vger.kernel.org      # 5.8
    Cc: Qiushi Wu <wu000273@umn.edu>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211201132528.30025-2-johan@kernel.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware: qemu_fw_cfg: fix sysfs information leak [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Dec 1 14:25:27 2021 +0100

    firmware: qemu_fw_cfg: fix sysfs information leak
    
    commit 1b656e9aad7f4886ed466094d1dc5ee4dd900d20 upstream.
    
    Make sure to always NUL-terminate file names retrieved from the firmware
    to avoid accessing data beyond the entry slab buffer and exposing it
    through sysfs in case the firmware data is corrupt.
    
    Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
    Cc: stable@vger.kernel.org      # 4.6
    Cc: Gabriel Somlo <somlo@cmu.edu>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211201132528.30025-4-johan@kernel.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: s390: Clarify SIGP orders versus STOP/RESTART [+ + +]
Author: Eric Farman <farman@linux.ibm.com>
Date:   Mon Dec 13 22:05:50 2021 +0100

    KVM: s390: Clarify SIGP orders versus STOP/RESTART
    
    commit 812de04661c4daa7ac385c0dfd62594540538034 upstream.
    
    With KVM_CAP_S390_USER_SIGP, there are only five Signal Processor
    orders (CONDITIONAL EMERGENCY SIGNAL, EMERGENCY SIGNAL, EXTERNAL CALL,
    SENSE, and SENSE RUNNING STATUS) which are intended for frequent use
    and thus are processed in-kernel. The remainder are sent to userspace
    with the KVM_CAP_S390_USER_SIGP capability. Of those, three orders
    (RESTART, STOP, and STOP AND STORE STATUS) have the potential to
    inject work back into the kernel, and thus are asynchronous.
    
    Let's look for those pending IRQs when processing one of the in-kernel
    SIGP orders, and return BUSY (CC2) if one is in process. This is in
    agreement with the Principles of Operation, which states that only one
    order can be "active" on a CPU at a time.
    
    Cc: stable@vger.kernel.org
    Suggested-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Eric Farman <farman@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Link: https://lore.kernel.org/r/20211213210550.856213-2-farman@linux.ibm.com
    [borntraeger@linux.ibm.com: add stable tag]
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: don't print when fail to read/write pv eoi memory [+ + +]
Author: Li RongQing <lirongqing@baidu.com>
Date:   Thu Nov 4 19:56:13 2021 +0800

    KVM: x86: don't print when fail to read/write pv eoi memory
    
    commit ce5977b181c1613072eafbc7546bcb6c463ea68c upstream.
    
    If guest gives MSR_KVM_PV_EOI_EN a wrong value, this printk() will
    be trigged, and kernel log is spammed with the useless message
    
    Fixes: 0d88800d5472 ("kvm: x86: ioapic and apic debug macros cleanup")
    Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Cc: stable@kernel.org
    Message-Id: <1636026974-50555-1-git-send-email-lirongqing@baidu.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Register perf callbacks after calling vendor's hardware_setup() [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Nov 11 02:07:23 2021 +0000

    KVM: x86: Register perf callbacks after calling vendor's hardware_setup()
    
    commit 5c7df80e2ce4c954c80eb4ecf5fa002a5ff5d2d6 upstream.
    
    Wait to register perf callbacks until after doing vendor hardaware setup.
    VMX's hardware_setup() configures Intel Processor Trace (PT) mode, and a
    future fix to register the Intel PT guest interrupt hook if and only if
    Intel PT is exposed to the guest will consume the configured PT mode.
    
    Delaying registration to hardware setup is effectively a nop as KVM's perf
    hooks all pivot on the per-CPU current_vcpu, which is non-NULL only when
    KVM is handling an IRQ/NMI in a VM-Exit path.  I.e. current_vcpu will be
    NULL throughout both kvm_arch_init() and kvm_arch_hardware_setup().
    
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20211111020738.2512932-3-seanjc@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Register Processor Trace interrupt hook iff PT enabled in guest [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Nov 11 02:07:24 2021 +0000

    KVM: x86: Register Processor Trace interrupt hook iff PT enabled in guest
    
    commit f4b027c5c8199abd4fb6f00d67d380548dbfdfa8 upstream.
    
    Override the Processor Trace (PT) interrupt handler for guest mode if and
    only if PT is configured for host+guest mode, i.e. is being used
    independently by both host and guest.  If PT is configured for system
    mode, the host fully controls PT and must handle all events.
    
    Fixes: 8479e04e7d6b ("KVM: x86: Inject PMI for KVM guest")
    Reported-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reported-by: Artem Kashkanov <artem.kashkanov@intel.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20211111020738.2512932-4-seanjc@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: remove PMU FIXED_CTR3 from msrs_to_save_all [+ + +]
Author: Wei Wang <wei.w.wang@intel.com>
Date:   Fri Dec 17 07:49:34 2021 -0500

    KVM: x86: remove PMU FIXED_CTR3 from msrs_to_save_all
    
    commit 9fb12fe5b93b94b9e607509ba461e17f4cc6a264 upstream.
    
    The fixed counter 3 is used for the Topdown metrics, which hasn't been
    enabled for KVM guests. Userspace accessing to it will fail as it's not
    included in get_fixed_pmc(). This breaks KVM selftests on ICX+ machines,
    which have this counter.
    
    To reproduce it on ICX+ machines, ./state_test reports:
    ==== Test Assertion Failure ====
    lib/x86_64/processor.c:1078: r == nmsrs
    pid=4564 tid=4564 - Argument list too long
    1  0x000000000040b1b9: vcpu_save_state at processor.c:1077
    2  0x0000000000402478: main at state_test.c:209 (discriminator 6)
    3  0x00007fbe21ed5f92: ?? ??:0
    4  0x000000000040264d: _start at ??:?
     Unexpected result from KVM_GET_MSRS, r: 17 (failed MSR was 0x30c)
    
    With this patch, it works well.
    
    Signed-off-by: Wei Wang <wei.w.wang@intel.com>
    Message-Id: <20211217124934.32893-1-wei.w.wang@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Fixes: e2ada66ec418 ("kvm: x86: Add Intel PMU MSRs to msrs_to_save[]")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.15.16 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 20 09:13:16 2022 +0100

    Linux 5.15.16
    
    Link: https://lore.kernel.org/r/20220118160451.879092022@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: uvcvideo: fix division by zero at stream start [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Oct 26 11:55:11 2021 +0200

    media: uvcvideo: fix division by zero at stream start
    
    commit 8aa637bf6d70d2fb2ad4d708d8b9dd02b1c095df upstream.
    
    Add the missing bulk-endpoint max-packet sanity check to
    uvc_video_start_transfer() to avoid division by zero in
    uvc_alloc_urb_buffers() in case a malicious device has broken
    descriptors (or when doing descriptor fuzz testing).
    
    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).
    
    Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver")
    Cc: stable@vger.kernel.org      # 2.6.26
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: fixup CFI on ixp4xx [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Sep 27 16:10:37 2021 +0200

    mtd: fixup CFI on ixp4xx
    
    commit 603362b4a58393061dcfed1c7f0d0fd4aba61126 upstream.
    
    drivers/mtd/maps/ixp4xx.c requires MTD_CFI_BE_BYTE_SWAP to be set
    in order to compile.
    
    drivers/mtd/maps/ixp4xx.c:57:4: error: #error CONFIG_MTD_CFI_BE_BYTE_SWAP required
    
    This patch avoids the #error output by enforcing the policy in
    Kconfig. Not sure if this is the right approach, but it helps doing
    randconfig builds.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210927141045.1597593-1-arnd@kernel.org
    Cc: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
orangefs: Fix the size of a memory allocation in orangefs_bufmap_alloc() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Dec 27 19:09:18 2021 +0100

    orangefs: Fix the size of a memory allocation in orangefs_bufmap_alloc()
    
    commit 40a74870b2d1d3d44e13b3b73c6571dd34f5614d upstream.
    
    'buffer_index_array' really looks like a bitmap. So it should be allocated
    as such.
    When kzalloc is called, a number of bytes is expected, but a number of
    longs is passed instead.
    
    In get(), if not enough memory is allocated, un-allocated memory may be
    read or written.
    
    So use bitmap_zalloc() to safely allocate the correct memory size and
    avoid un-expected behavior.
    
    While at it, change the corresponding kfree() into bitmap_free() to keep
    the semantic.
    
    Fixes: ea2c9c9f6574 ("orangefs: bufmap rewrite")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf annotate: Avoid TUI crash when navigating in the annotation of recursive functions [+ + +]
Author: Dario Petrillo <dario.pk1@gmail.com>
Date:   Mon Jan 10 00:44:41 2022 +0100

    perf annotate: Avoid TUI crash when navigating in the annotation of recursive functions
    
    commit d5962fb7d69073bf68fb647531cfd4f0adf84be3 upstream.
    
    In 'perf report', entering a recursive function from inside of itself
    (either directly of indirectly through some other function) results in
    calling symbol__annotate2 multiple() times, and freeing the whole
    disassembly when exiting from the innermost instance.
    
    The first issue causes the function's disassembly to be duplicated, and
    the latter a heap use-after-free (and crash) when trying to access the
    disassembly again.
    
    I reproduced the bug on perf 5.11.22 (Ubuntu 20.04.3 LTS) and 5.16.rc8
    with the following testcase (compile with gcc recursive.c -o recursive).
    To reproduce:
    
    - perf record ./recursive
    - perf report
    - enter fibonacci and annotate it
    - move the cursor on one of the "callq fibonacci" instructions and press enter
      - at this point there will be two copies of the function in the disassembly
    - go back by pressing q, and perf will crash
    
      #include <stdio.h>
    
      int fibonacci(int n)
      {
          if(n <= 2) return 1;
          return fibonacci(n-1) + fibonacci(n-2);
      }
    
      int main()
      {
          printf("%d\n", fibonacci(40));
      }
    
    This patch addresses the issue by annotating a function and freeing the
    associated memory on exit only if no annotation is already present, so
    that a recursive function is only annotated on entry.
    
    Signed-off-by: Dario Petrillo <dario.pk1@gmail.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@kernel.org
    Link: http://lore.kernel.org/lkml/20220109234441.325106-1-dario.pk1@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf: Protect perf_guest_cbs with RCU [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Nov 11 02:07:22 2021 +0000

    perf: Protect perf_guest_cbs with RCU
    
    commit ff083a2d972f56bebfd82409ca62e5dfce950961 upstream.
    
    Protect perf_guest_cbs with RCU to fix multiple possible errors.  Luckily,
    all paths that read perf_guest_cbs already require RCU protection, e.g. to
    protect the callback chains, so only the direct perf_guest_cbs touchpoints
    need to be modified.
    
    Bug #1 is a simple lack of WRITE_ONCE/READ_ONCE behavior to ensure
    perf_guest_cbs isn't reloaded between a !NULL check and a dereference.
    Fixed via the READ_ONCE() in rcu_dereference().
    
    Bug #2 is that on weakly-ordered architectures, updates to the callbacks
    themselves are not guaranteed to be visible before the pointer is made
    visible to readers.  Fixed by the smp_store_release() in
    rcu_assign_pointer() when the new pointer is non-NULL.
    
    Bug #3 is that, because the callbacks are global, it's possible for
    readers to run in parallel with an unregisters, and thus a module
    implementing the callbacks can be unloaded while readers are in flight,
    resulting in a use-after-free.  Fixed by a synchronize_rcu() call when
    unregistering callbacks.
    
    Bug #1 escaped notice because it's extremely unlikely a compiler will
    reload perf_guest_cbs in this sequence.  perf_guest_cbs does get reloaded
    for future derefs, e.g. for ->is_user_mode(), but the ->is_in_guest()
    guard all but guarantees the consumer will win the race, e.g. to nullify
    perf_guest_cbs, KVM has to completely exit the guest and teardown down
    all VMs before KVM start its module unload / unregister sequence.  This
    also makes it all but impossible to encounter bug #3.
    
    Bug #2 has not been a problem because all architectures that register
    callbacks are strongly ordered and/or have a static set of callbacks.
    
    But with help, unloading kvm_intel can trigger bug #1 e.g. wrapping
    perf_guest_cbs with READ_ONCE in perf_misc_flags() while spamming
    kvm_intel module load/unload leads to:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000000
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 0 P4D 0
      Oops: 0000 [#1] PREEMPT SMP
      CPU: 6 PID: 1825 Comm: stress Not tainted 5.14.0-rc2+ #459
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
      RIP: 0010:perf_misc_flags+0x1c/0x70
      Call Trace:
       perf_prepare_sample+0x53/0x6b0
       perf_event_output_forward+0x67/0x160
       __perf_event_overflow+0x52/0xf0
       handle_pmi_common+0x207/0x300
       intel_pmu_handle_irq+0xcf/0x410
       perf_event_nmi_handler+0x28/0x50
       nmi_handle+0xc7/0x260
       default_do_nmi+0x6b/0x170
       exc_nmi+0x103/0x130
       asm_exc_nmi+0x76/0xbf
    
    Fixes: 39447b386c84 ("perf: Enhance perf to allow for guest statistic collection from host")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20211111020738.2512932-2-seanjc@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
remoteproc: qcom: pas: Add missing power-domain "mxc" for CDSP [+ + +]
Author: Sibi Sankar <sibis@codeaurora.org>
Date:   Fri Jun 25 00:03:25 2021 +0530

    remoteproc: qcom: pas: Add missing power-domain "mxc" for CDSP
    
    commit dd585d9bfbf06fd08a6326c82978be1f06e7d1bd upstream.
    
    Add missing power-domain "mxc" required by CDSP PAS remoteproc on SM8350
    SoC.
    
    Fixes: e8b4e9a21af7 ("remoteproc: qcom: pas: Add SM8350 PAS remoteprocs")
    Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
    Cc: stable@vger.kernel.org
    Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/1624559605-29847-1-git-send-email-sibis@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

remoteproc: qcom: pil_info: Don't memcpy_toio more than is provided [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Tue Nov 16 22:54:54 2021 -0800

    remoteproc: qcom: pil_info: Don't memcpy_toio more than is provided
    
    commit fdc12231d885119cc2e2b4f3e0fbba3155f37a56 upstream.
    
    If the string passed into qcom_pil_info_store() isn't as long as
    PIL_RELOC_NAME_LEN we'll try to copy the string assuming the length is
    PIL_RELOC_NAME_LEN to the io space and go beyond the bounds of the
    string. Let's only copy as many byes as the string is long, ignoring the
    NUL terminator.
    
    This fixes the following KASAN error:
    
     BUG: KASAN: global-out-of-bounds in __memcpy_toio+0x124/0x140
     Read of size 1 at addr ffffffd35086e386 by task rmtfs/2392
    
     CPU: 2 PID: 2392 Comm: rmtfs Tainted: G        W         5.16.0-rc1-lockdep+ #10
     Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
     Call trace:
      dump_backtrace+0x0/0x410
      show_stack+0x24/0x30
      dump_stack_lvl+0x7c/0xa0
      print_address_description+0x78/0x2bc
      kasan_report+0x160/0x1a0
      __asan_report_load1_noabort+0x44/0x50
      __memcpy_toio+0x124/0x140
      qcom_pil_info_store+0x298/0x358 [qcom_pil_info]
      q6v5_start+0xdf0/0x12e0 [qcom_q6v5_mss]
      rproc_start+0x178/0x3a0
      rproc_boot+0x5f0/0xb90
      state_store+0x78/0x1bc
      dev_attr_store+0x70/0x90
      sysfs_kf_write+0xf4/0x118
      kernfs_fop_write_iter+0x208/0x300
      vfs_write+0x55c/0x804
      ksys_pwrite64+0xc8/0x134
      __arm64_compat_sys_aarch32_pwrite64+0xc4/0xdc
      invoke_syscall+0x78/0x20c
      el0_svc_common+0x11c/0x1f0
      do_el0_svc_compat+0x50/0x60
      el0_svc_compat+0x5c/0xec
      el0t_32_sync_handler+0xc0/0xf0
      el0t_32_sync+0x1a4/0x1a8
    
     The buggy address belongs to the variable:
      .str.59+0x6/0xffffffffffffec80 [qcom_q6v5_mss]
    
     Memory state around the buggy address:
      ffffffd35086e280: 00 00 00 00 02 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
      ffffffd35086e300: 00 02 f9 f9 f9 f9 f9 f9 00 00 00 06 f9 f9 f9 f9
     >ffffffd35086e380: 06 f9 f9 f9 05 f9 f9 f9 00 00 00 00 00 06 f9 f9
                        ^
      ffffffd35086e400: f9 f9 f9 f9 01 f9 f9 f9 04 f9 f9 f9 00 00 01 f9
      ffffffd35086e480: f9 f9 f9 f9 00 00 00 00 00 00 00 01 f9 f9 f9 f9
    
    Fixes: 549b67da660d ("remoteproc: qcom: Introduce helper to store pil info in IMEM")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211117065454.4142936-1-swboyd@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled [+ + +]
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Dec 15 11:11:05 2021 -0600

    rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled
    
    commit 8b144dedb928e4e2f433a328d58f44c3c098d63e upstream.
    
    Syzbot reports the following WARNING:
    
    [200~raw_local_irq_restore() called with IRQs enabled
    WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10
       warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10
    
    Hardware initialization for the rtl8188cu can run for as long as 350 ms,
    and the routine may be called with interrupts disabled. To avoid locking
    the machine for this long, the current routine saves the interrupt flags
    and enables local interrupts. The problem is that it restores the flags
    at the end without disabling local interrupts first.
    
    This patch fixes commit a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long
    disable of IRQs").
    
    Reported-by: syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Fixes: a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vfs: fs_context: fix up param length parsing in legacy_parse_param [+ + +]
Author: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
Date:   Tue Jan 18 08:06:04 2022 +0100

    vfs: fs_context: fix up param length parsing in legacy_parse_param
    
    commit 722d94847de29310e8aa03fcbdb41fc92c521756 upstream.
    
    The "PAGE_SIZE - 2 - size" calculation in legacy_parse_param() is an
    unsigned type so a large value of "size" results in a high positive
    value instead of a negative value as expected.  Fix this by getting rid
    of the subtraction.
    
    Signed-off-by: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
    Signed-off-by: William Liu <willsroot@protonmail.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
video: vga16fb: Only probe for EGA and VGA 16 color graphic cards [+ + +]
Author: Javier Martinez Canillas <javierm@redhat.com>
Date:   Mon Jan 10 10:56:25 2022 +0100

    video: vga16fb: Only probe for EGA and VGA 16 color graphic cards
    
    commit 0499f419b76f94ede08304aad5851144813ac55c upstream.
    
    The vga16fb framebuffer driver only supports Enhanced Graphics Adapter
    (EGA) and Video Graphics Array (VGA) 16 color graphic cards.
    
    But it doesn't check if the adapter is one of those or if a VGA16 mode
    is used. This means that the driver will be probed even if a VESA BIOS
    Extensions (VBE) or Graphics Output Protocol (GOP) interface is used.
    
    This issue has been present for a long time but it was only exposed by
    commit d391c5827107 ("drivers/firmware: move x86 Generic System
    Framebuffers support") since the platform device registration to match
    the {vesa,efi}fb drivers is done later as a consequence of that change.
    
    All non-x86 architectures though treat orig_video_isVGA as a boolean so
    only do the supported video mode check for x86 and not for other arches.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215001
    Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support")
    Reported-by: Kris Karas <bugs-a21@moonlit-rail.com>
    Cc: <stable@vger.kernel.org> # 5.15.x
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Tested-by: Kris Karas <bugs-a21@moonlit-rail.com>
    Acked-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220110095625.278836-3-javierm@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>