commit 5fd3e07fd10e79694bff69fff1d38e97b47e77f0 Author: Greg Kroah-Hartman Date: Thu Jan 20 09:12:22 2022 +0100 Linux 5.16.2 Link: https://lore.kernel.org/r/20220118160452.384322748@linuxfoundation.org Tested-by: Jeffrin Jose T Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Zan Aziz Tested-by: Ron Economos Tested-by: Rudi Heitbaum Tested-by: Linux Kernel Functional Testing Tested-by: Ronald Warsow Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit a498f4a42b8193934a6888a4a548c1c107636941 Author: Takashi Iwai 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: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 21ad9041b6155ad5c9d8cab6ad72a0135750c957 Author: Baole Fang 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 Cc: Link: https://lore.kernel.org/r/20220105140856.4855-1-fbl718@163.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5053b09e0e906843de2fec8e435a6b6596e9fd0b Author: Sameer Pujar 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 Reviewed-by: Dmitry Osipenko Link: https://lore.kernel.org/r/1640260431-11613-2-git-send-email-spujar@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ea3fcb111c87197ea0f48431fbd7bef7302f91a7 Author: Bart Kroon 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 Cc: Link: https://lore.kernel.org/r/JAG24R.7NLJGWBF4G8U@tarmack.eu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 73990b61c549c5891b06fd58413af0d18b0ccb06 Author: Christian Lachner 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 Fixes: 0d45e86d2267d ("ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master") Cc: Link: https://lore.kernel.org/r/20220103140517.30273-2-gladiac@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2ac0c35159be625c1eda692ee86cc980c15cab15 Author: Kai-Heng Feng 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 Cc: Link: https://lore.kernel.org/r/20211224035015.310068-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 08968ce43f9df46b9d45457918ac1c0f0227686a Author: Arie Geiger 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 Cc: Link: https://lore.kernel.org/r/20211223232857.30741-1-arsgeiger@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7faa2fb7bcd1bf5453f8328cafa50757c7250878 Author: Dario Petrillo 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 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 Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: stable@kernel.org Link: http://lore.kernel.org/lkml/20220109234441.325106-1-dario.pk1@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 1f21b193707e1f2a1e2e5a8b1515fb896f5742ea Author: Johan Hovold 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 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211201132528.30025-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fd8a2f12de64f456ed2450f0fd6bb0df6bbee462 Author: Johan Hovold 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 Cc: Kees Cook Cc: Greg Kroah-Hartman Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211201132528.30025-2-johan@kernel.org Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 261f47d05859fafaa0586c07568edbaf5cf61a0c Author: Johan Hovold 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 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211201132528.30025-4-johan@kernel.org Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 105ee59fc79edf9f2297eeb5cb539cdd174186c0 Author: Larry Finger 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 Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman commit 230d1fa69ff8069953ffa7639a660219016ee665 Author: Johan Hovold 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 Reviewed-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c923276ddd49a299fdbd7858bcf15d7a1700932d Author: Javier Martinez Canillas 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 Cc: # 5.15.x Signed-off-by: Javier Martinez Canillas Tested-by: Kris Karas Acked-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220110095625.278836-3-javierm@redhat.com Signed-off-by: Greg Kroah-Hartman commit 0b1a05b219fe9da9384139474b8de867ab240cf1 Author: Dominique Martinet Date: Mon Jan 10 20:10:31 2022 +0900 9p: fix enodata when reading growing file commit 19d1c32652bbbf406063025354845fdddbcecd3a upstream. Reading from a file that was just extended by a write, but the write had not yet reached the server would return ENODATA as illustrated by this command: $ xfs_io -c 'open -ft test' -c 'w 4096 1000' -c 'r 0 1000' wrote 1000/1000 bytes at offset 4096 1000.000000 bytes, 1 ops; 0.0001 sec (5.610 MiB/sec and 5882.3529 ops/sec) pread: No data available Fix this case by having netfs assume zeroes when reads from server come short like AFS and CEPH do Link: https://lkml.kernel.org/r/20220110111444.926753-1-asmadeus@codewreck.org Cc: stable@vger.kernel.org Fixes: eb497943fa21 ("9p: Convert to using the netfs helper lib to do reads and caching") Co-authored-by: David Howells Reviewed-by: David Howells Tested-by: David Howells Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 4947e1735a8780843ea47ea65eb994fa82d72a39 Author: Christian Brauner 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 Cc: Latchesar Ionkov Cc: Dominique Martinet Cc: stable@kernel.org Cc: v9fs-developer@lists.sourceforge.net Reported-by: syzbot+dfac92a50024b54acaa4@syzkaller.appspotmail.com Signed-off-by: Christian Brauner [Dominique: do not set a/mtime with just ATTR_A/MTIME as discussed] Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit cda396e5ce51dbe231f0af1d399aef40d1de7b3a Author: Chuck Lever Date: Tue Dec 21 11:52:06 2021 -0500 NFSD: Fix zero-length NFSv3 WRITEs commit 6a2f774424bfdcc2df3e17de0cefe74a4269cad5 upstream. The Linux NFS server currently responds to a zero-length NFSv3 WRITE request with NFS3ERR_IO. It responds to a zero-length NFSv4 WRITE with NFS4_OK and count of zero. RFC 1813 says of the WRITE procedure's @count argument: count The number of bytes of data to be written. If count is 0, the WRITE will succeed and return a count of 0, barring errors due to permissions checking. RFC 8881 has similar language for NFSv4, though NFSv4 removed the explicit @count argument because that value is already contained in the opaque payload array. The synthetic client pynfs's WRT4 and WRT15 tests do emit zero- length WRITEs to exercise this spec requirement. Commit fdec6114ee1f ("nfsd4: zero-length WRITE should succeed") addressed the same problem there with the same fix. But interestingly the Linux NFS client does not appear to emit zero- length WRITEs, instead squelching them. I'm not aware of a test that can generate such WRITEs for NFSv3, so I wrote a naive C program to generate a zero-length WRITE and test this fix. Fixes: 8154ef2776aa ("NFSD: Clean up legacy NFS WRITE argument XDR decoders") Reported-by: Trond Myklebust Signed-off-by: Chuck Lever Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f3f2900c93e21e988579a992021704ef3d502599 Author: Sibi Sankar 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 Cc: stable@vger.kernel.org Tested-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1624559605-29847-1-git-send-email-sibis@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 07f5f305ed81e677fa719cceba8eee8290f49810 Author: Eric Farman 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 Signed-off-by: Eric Farman Reviewed-by: Christian Borntraeger Acked-by: David Hildenbrand 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 Signed-off-by: Greg Kroah-Hartman commit 60af2066bc5d7816627f1595ce4c3e6fd5ffe0ae Author: Li RongQing 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 Reviewed-by: Vitaly Kuznetsov Signed-off-by: Li RongQing Cc: stable@kernel.org Message-Id: <1636026974-50555-1-git-send-email-lirongqing@baidu.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ec985a8dfbe9c023d8ebd15b5f83a899b9572494 Author: Sean Christopherson 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 Reported-by: Artem Kashkanov Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Acked-by: Paolo Bonzini Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211111020738.2512932-4-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 51d24f081b90e51255b42ea34ababead7bcba91b Author: Sean Christopherson 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 Signed-off-by: Peter Zijlstra (Intel) Acked-by: Paolo Bonzini Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211111020738.2512932-3-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 68fe61050dc2424733b735db7c9bbc1aed9fa317 Author: Sean Christopherson 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 Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Paolo Bonzini Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211111020738.2512932-2-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 8b1530a3772ae5b49c6d8d171fd3146bb947430f Author: Jamie Hill-Daniel 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 Signed-off-by: William Liu Tested-by: Salvatore Bonaccorso Tested-by: Thadeu Lima de Souza Cascardo Acked-by: Dan Carpenter Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit af8ad4718278236442e6a8b031ae5a99096ec98f Author: Stephen Boyd 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 Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211117065454.4142936-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman commit 931b93ac1fce734afa6e4ba3b1e5a05e169db32b Author: Christophe JAILLET 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 Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit 16a1622c34243f7060ad5bf13fc34788f7304a22 Author: Mario Limonciello 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 Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3bddfeab42abf0cda1ffa181722befaf664a4453 Author: NeilBrown 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 Cc: Al Viro Signed-off-by: NeilBrown Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman