--- /dev/null
+From e5b0d06d9b10f5f43101bd6598b076c347f9295f Mon Sep 17 00:00:00 2001
+From: Alexander Potapenko <glider@google.com>
+Date: Fri, 4 Nov 2022 18:58:49 +0100
+Subject: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()
+
+From: Alexander Potapenko <glider@google.com>
+
+commit e5b0d06d9b10f5f43101bd6598b076c347f9295f upstream.
+
+`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,
+which may carry uninitialized data to the userspace, as observed by
+KMSAN:
+
+ BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121
+ instrument_copy_to_user ./include/linux/instrumented.h:121
+ _copy_to_user+0x5f/0xb0 lib/usercopy.c:33
+ copy_to_user ./include/linux/uaccess.h:169
+ vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431
+ vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925
+ vfs_ioctl fs/ioctl.c:51
+ ...
+
+ Uninit was stored to memory at:
+ kmemdup+0x74/0xb0 mm/util.c:131
+ dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271
+ vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339
+ qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479
+ qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
+ qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
+ vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940
+ vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488
+ vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927
+ ...
+
+ Local variable ev created at:
+ qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456
+ qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
+ qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
+
+ Bytes 28-31 of 48 are uninitialized
+ Memory access of size 48 starts at ffff888035155e00
+ Data copied to user address 0000000020000100
+
+Use memset() to prevent the infoleaks.
+
+Also speculatively fix qp_notify_peer_local(), which may suffer from the
+same problem.
+
+Reported-by: syzbot+39be4da489ed2493ba25@syzkaller.appspotmail.com
+Cc: stable <stable@kernel.org>
+Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
+Signed-off-by: Alexander Potapenko <glider@google.com>
+Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
+Link: https://lore.kernel.org/r/20221104175849.2782567-1-glider@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/vmw_vmci/vmci_queue_pair.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
++++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
+@@ -952,6 +952,7 @@ static int qp_notify_peer_local(bool att
+ u32 context_id = vmci_get_context_id();
+ struct vmci_event_qp ev;
+
++ memset(&ev, 0, sizeof(ev));
+ ev.msg.hdr.dst = vmci_make_handle(context_id, VMCI_EVENT_HANDLER);
+ ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+ VMCI_CONTEXT_RESOURCE_ID);
+@@ -1563,6 +1564,7 @@ static int qp_notify_peer(bool attach,
+ * kernel.
+ */
+
++ memset(&ev, 0, sizeof(ev));
+ ev.msg.hdr.dst = vmci_make_handle(peer_id, VMCI_EVENT_HANDLER);
+ ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+ VMCI_CONTEXT_RESOURCE_ID);
--- /dev/null
+From 39a72dbfe188291b156dd6523511e3d5761ce775 Mon Sep 17 00:00:00 2001
+From: Yann Gautier <yann.gautier@foss.st.com>
+Date: Fri, 28 Oct 2022 09:37:40 +0200
+Subject: mmc: core: properly select voltage range without power cycle
+
+From: Yann Gautier <yann.gautier@foss.st.com>
+
+commit 39a72dbfe188291b156dd6523511e3d5761ce775 upstream.
+
+In mmc_select_voltage(), if there is no full power cycle, the voltage
+range selected at the end of the function will be on a single range
+(e.g. 3.3V/3.4V). To keep a range around the selected voltage (3.2V/3.4V),
+the mask shift should be reduced by 1.
+
+This issue was triggered by using a specific SD-card (Verbatim Premium
+16GB UHS-1) on an STM32MP157C-DK2 board. This board cannot do UHS modes
+and there is no power cycle. And the card was failing to switch to
+high-speed mode. When adding the range 3.2V/3.3V for this card with the
+proposed shift change, the card can switch to high-speed mode.
+
+Fixes: ce69d37b7d8f ("mmc: core: Prevent violation of specs while initializing cards")
+Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221028073740.7259-1-yann.gautier@foss.st.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/core.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/core/core.c
++++ b/drivers/mmc/core/core.c
+@@ -1463,7 +1463,13 @@ u32 mmc_select_voltage(struct mmc_host *
+ mmc_power_cycle(host, ocr);
+ } else {
+ bit = fls(ocr) - 1;
+- ocr &= 3 << bit;
++ /*
++ * The bit variable represents the highest voltage bit set in
++ * the OCR register.
++ * To keep a range of 2 values (e.g. 3.2V/3.3V and 3.3V/3.4V),
++ * we must shift the mask '3' with (bit - 1).
++ */
++ ocr &= 3 << (bit - 1);
+ if (bit != host->ios.vdd)
+ dev_warn(mmc_dev(host), "exceeding card's volts\n");
+ }
--- /dev/null
+From 222cfa0118aa68687ace74aab8fdf77ce8fbd7e6 Mon Sep 17 00:00:00 2001
+From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+Date: Mon, 14 Nov 2022 16:31:00 +0800
+Subject: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()
+
+From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+
+commit 222cfa0118aa68687ace74aab8fdf77ce8fbd7e6 upstream.
+
+pci_get_device() will increase the reference count for the returned
+pci_dev. We need to use pci_dev_put() to decrease the reference count
+before amd_probe() returns. There is no problem for the 'smbus_dev ==
+NULL' branch because pci_dev_put() can also handle the NULL input
+parameter case.
+
+Fixes: 659c9bc114a8 ("mmc: sdhci-pci: Build o2micro support in the same module")
+Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221114083100.149200-1-wangxiongfeng2@huawei.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pci-core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-pci-core.c
++++ b/drivers/mmc/host/sdhci-pci-core.c
+@@ -1277,6 +1277,8 @@ static int amd_probe(struct sdhci_pci_ch
+ }
+ }
+
++ pci_dev_put(smbus_dev);
++
+ if (gen == AMD_CHIPSET_BEFORE_ML || gen == AMD_CHIPSET_CZ)
+ chip->quirks2 |= SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD;
+
--- /dev/null
+From 8cccf05fe857a18ee26e20d11a8455a73ffd4efd Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Date: Fri, 4 Nov 2022 23:29:59 +0900
+Subject: nilfs2: fix use-after-free bug of ns_writer on remount
+
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+
+commit 8cccf05fe857a18ee26e20d11a8455a73ffd4efd upstream.
+
+If a nilfs2 filesystem is downgraded to read-only due to metadata
+corruption on disk and is remounted read/write, or if emergency read-only
+remount is performed, detaching a log writer and synchronizing the
+filesystem can be done at the same time.
+
+In these cases, use-after-free of the log writer (hereinafter
+nilfs->ns_writer) can happen as shown in the scenario below:
+
+ Task1 Task2
+ -------------------------------- ------------------------------
+ nilfs_construct_segment
+ nilfs_segctor_sync
+ init_wait
+ init_waitqueue_entry
+ add_wait_queue
+ schedule
+ nilfs_remount (R/W remount case)
+ nilfs_attach_log_writer
+ nilfs_detach_log_writer
+ nilfs_segctor_destroy
+ kfree
+ finish_wait
+ _raw_spin_lock_irqsave
+ __raw_spin_lock_irqsave
+ do_raw_spin_lock
+ debug_spin_lock_before <-- use-after-free
+
+While Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1
+waked up, Task1 accesses nilfs->ns_writer which is already freed. This
+scenario diagram is based on the Shigeru Yoshida's post [1].
+
+This patch fixes the issue by not detaching nilfs->ns_writer on remount so
+that this UAF race doesn't happen. Along with this change, this patch
+also inserts a few necessary read-only checks with superblock instance
+where only the ns_writer pointer was used to check if the filesystem is
+read-only.
+
+Link: https://syzkaller.appspot.com/bug?id=79a4c002e960419ca173d55e863bd09e8112df8b
+Link: https://lkml.kernel.org/r/20221103141759.1836312-1-syoshida@redhat.com [1]
+Link: https://lkml.kernel.org/r/20221104142959.28296-1-konishi.ryusuke@gmail.com
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Reported-by: syzbot+f816fa82f8783f7a02bb@syzkaller.appspotmail.com
+Reported-by: Shigeru Yoshida <syoshida@redhat.com>
+Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nilfs2/segment.c | 15 ++++++++-------
+ fs/nilfs2/super.c | 2 --
+ 2 files changed, 8 insertions(+), 9 deletions(-)
+
+--- a/fs/nilfs2/segment.c
++++ b/fs/nilfs2/segment.c
+@@ -331,7 +331,7 @@ void nilfs_relax_pressure_in_lock(struct
+ struct the_nilfs *nilfs = sb->s_fs_info;
+ struct nilfs_sc_info *sci = nilfs->ns_writer;
+
+- if (!sci || !sci->sc_flush_request)
++ if (sb_rdonly(sb) || unlikely(!sci) || !sci->sc_flush_request)
+ return;
+
+ set_bit(NILFS_SC_PRIOR_FLUSH, &sci->sc_flags);
+@@ -2256,7 +2256,7 @@ int nilfs_construct_segment(struct super
+ struct nilfs_transaction_info *ti;
+ int err;
+
+- if (!sci)
++ if (sb_rdonly(sb) || unlikely(!sci))
+ return -EROFS;
+
+ /* A call inside transactions causes a deadlock. */
+@@ -2295,7 +2295,7 @@ int nilfs_construct_dsync_segment(struct
+ struct nilfs_transaction_info ti;
+ int err = 0;
+
+- if (!sci)
++ if (sb_rdonly(sb) || unlikely(!sci))
+ return -EROFS;
+
+ nilfs_transaction_lock(sb, &ti, 0);
+@@ -2792,11 +2792,12 @@ int nilfs_attach_log_writer(struct super
+
+ if (nilfs->ns_writer) {
+ /*
+- * This happens if the filesystem was remounted
+- * read/write after nilfs_error degenerated it into a
+- * read-only mount.
++ * This happens if the filesystem is made read-only by
++ * __nilfs_error or nilfs_remount and then remounted
++ * read/write. In these cases, reuse the existing
++ * writer.
+ */
+- nilfs_detach_log_writer(sb);
++ return 0;
+ }
+
+ nilfs->ns_writer = nilfs_segctor_new(sb, root);
+--- a/fs/nilfs2/super.c
++++ b/fs/nilfs2/super.c
+@@ -1148,8 +1148,6 @@ static int nilfs_remount(struct super_bl
+ if ((bool)(*flags & MS_RDONLY) == sb_rdonly(sb))
+ goto out;
+ if (*flags & MS_RDONLY) {
+- /* Shutting down log writer */
+- nilfs_detach_log_writer(sb);
+ sb->s_flags |= MS_RDONLY;
+
+ /*
dm-ioctl-fix-misbehavior-if-list_versions-races-with-module-loading.patch
serial-8250-fall-back-to-non-dma-rx-if-iir_rdi-occurs.patch
serial-8250_lpss-configure-dma-also-w-o-dma-filter.patch
+mmc-core-properly-select-voltage-range-without-power-cycle.patch
+mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch
+misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch
+nilfs2-fix-use-after-free-bug-of-ns_writer-on-remount.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
