From: Greg Kroah-Hartman Date: Tue, 3 Nov 2020 14:39:31 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.14.204~31 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b46be4adeda331af89a1c6d6883693ceb6998e9d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: dmaengine-dma-jz4780-fix-race-in-jz4780_dma_tx_status.patch iio-gyro-itg3200-fix-timestamp-alignment-and-prevent-data-leak.patch powerpc-powernv-elog-fix-race-while-processing-opal-error-log-event.patch ubifs-dent-fix-some-potential-memory-leaks-while-iterating-entries.patch --- diff --git a/queue-4.4/dmaengine-dma-jz4780-fix-race-in-jz4780_dma_tx_status.patch b/queue-4.4/dmaengine-dma-jz4780-fix-race-in-jz4780_dma_tx_status.patch new file mode 100644 index 00000000000..a1301a2e185 --- /dev/null +++ b/queue-4.4/dmaengine-dma-jz4780-fix-race-in-jz4780_dma_tx_status.patch @@ -0,0 +1,57 @@ +From baf6fd97b16ea8f981b8a8b04039596f32fc2972 Mon Sep 17 00:00:00 2001 +From: Paul Cercueil +Date: Sun, 4 Oct 2020 16:03:07 +0200 +Subject: dmaengine: dma-jz4780: Fix race in jz4780_dma_tx_status + +From: Paul Cercueil + +commit baf6fd97b16ea8f981b8a8b04039596f32fc2972 upstream. + +The jz4780_dma_tx_status() function would check if a channel's cookie +state was set to 'completed', and if not, it would enter the critical +section. However, in that time frame, the jz4780_dma_chan_irq() function +was able to set the cookie to 'completed', and clear the jzchan->vchan +pointer, which was deferenced in the critical section of the first +function. + +Fix this race by checking the channel's cookie state after entering the +critical function and not before. + +Fixes: d894fc6046fe ("dmaengine: jz4780: add driver for the Ingenic JZ4780 DMA controller") +Cc: stable@vger.kernel.org # v4.0 +Signed-off-by: Paul Cercueil +Reported-by: Artur Rojek +Tested-by: Artur Rojek +Link: https://lore.kernel.org/r/20201004140307.885556-1-paul@crapouillou.net +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/dma-jz4780.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/dma/dma-jz4780.c ++++ b/drivers/dma/dma-jz4780.c +@@ -563,11 +563,11 @@ static enum dma_status jz4780_dma_tx_sta + enum dma_status status; + unsigned long flags; + ++ spin_lock_irqsave(&jzchan->vchan.lock, flags); ++ + status = dma_cookie_status(chan, cookie, txstate); + if ((status == DMA_COMPLETE) || (txstate == NULL)) +- return status; +- +- spin_lock_irqsave(&jzchan->vchan.lock, flags); ++ goto out_unlock_irqrestore; + + vdesc = vchan_find_desc(&jzchan->vchan, cookie); + if (vdesc) { +@@ -584,6 +584,7 @@ static enum dma_status jz4780_dma_tx_sta + && jzchan->desc->status & (JZ_DMA_DCS_AR | JZ_DMA_DCS_HLT)) + status = DMA_ERROR; + ++out_unlock_irqrestore: + spin_unlock_irqrestore(&jzchan->vchan.lock, flags); + return status; + } diff --git a/queue-4.4/iio-gyro-itg3200-fix-timestamp-alignment-and-prevent-data-leak.patch b/queue-4.4/iio-gyro-itg3200-fix-timestamp-alignment-and-prevent-data-leak.patch new file mode 100644 index 00000000000..16dbd69b521 --- /dev/null +++ b/queue-4.4/iio-gyro-itg3200-fix-timestamp-alignment-and-prevent-data-leak.patch @@ -0,0 +1,60 @@ +From 10ab7cfd5522f0041028556dac864a003e158556 Mon Sep 17 00:00:00 2001 +From: Jonathan Cameron +Date: Wed, 22 Jul 2020 16:50:41 +0100 +Subject: iio:gyro:itg3200: Fix timestamp alignment and prevent data leak. + +From: Jonathan Cameron + +commit 10ab7cfd5522f0041028556dac864a003e158556 upstream. + +One of a class of bugs pointed out by Lars in a recent review. +iio_push_to_buffers_with_timestamp assumes the buffer used is aligned +to the size of the timestamp (8 bytes). This is not guaranteed in +this driver which uses a 16 byte array of smaller elements on the stack. +This is fixed by using an explicit c structure. As there are no +holes in the structure, there is no possiblity of data leakage +in this case. + +The explicit alignment of ts is not strictly necessary but potentially +makes the code slightly less fragile. It also removes the possibility +of this being cut and paste into another driver where the alignment +isn't already true. + +Fixes: 36e0371e7764 ("iio:itg3200: Use iio_push_to_buffers_with_timestamp()") +Reported-by: Lars-Peter Clausen +Signed-off-by: Jonathan Cameron +Reviewed-by: Andy Shevchenko +Cc: +Link: https://lore.kernel.org/r/20200722155103.979802-6-jic23@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/gyro/itg3200_buffer.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/iio/gyro/itg3200_buffer.c ++++ b/drivers/iio/gyro/itg3200_buffer.c +@@ -49,13 +49,20 @@ static irqreturn_t itg3200_trigger_handl + struct iio_poll_func *pf = p; + struct iio_dev *indio_dev = pf->indio_dev; + struct itg3200 *st = iio_priv(indio_dev); +- __be16 buf[ITG3200_SCAN_ELEMENTS + sizeof(s64)/sizeof(u16)]; ++ /* ++ * Ensure correct alignment and padding including for the ++ * timestamp that may be inserted. ++ */ ++ struct { ++ __be16 buf[ITG3200_SCAN_ELEMENTS]; ++ s64 ts __aligned(8); ++ } scan; + +- int ret = itg3200_read_all_channels(st->i2c, buf); ++ int ret = itg3200_read_all_channels(st->i2c, scan.buf); + if (ret < 0) + goto error_ret; + +- iio_push_to_buffers_with_timestamp(indio_dev, buf, pf->timestamp); ++ iio_push_to_buffers_with_timestamp(indio_dev, &scan, pf->timestamp); + + iio_trigger_notify_done(indio_dev->trig); + diff --git a/queue-4.4/powerpc-powernv-elog-fix-race-while-processing-opal-error-log-event.patch b/queue-4.4/powerpc-powernv-elog-fix-race-while-processing-opal-error-log-event.patch new file mode 100644 index 00000000000..200285f5831 --- /dev/null +++ b/queue-4.4/powerpc-powernv-elog-fix-race-while-processing-opal-error-log-event.patch @@ -0,0 +1,128 @@ +From aea948bb80b478ddc2448f7359d574387521a52d Mon Sep 17 00:00:00 2001 +From: Mahesh Salgaonkar +Date: Tue, 6 Oct 2020 13:02:18 +0530 +Subject: powerpc/powernv/elog: Fix race while processing OPAL error log event. + +From: Mahesh Salgaonkar + +commit aea948bb80b478ddc2448f7359d574387521a52d upstream. + +Every error log reported by OPAL is exported to userspace through a +sysfs interface and notified using kobject_uevent(). The userspace +daemon (opal_errd) then reads the error log and acknowledges the error +log is saved safely to disk. Once acknowledged the kernel removes the +respective sysfs file entry causing respective resources to be +released including kobject. + +However it's possible the userspace daemon may already be scanning +elog entries when a new sysfs elog entry is created by the kernel. +User daemon may read this new entry and ack it even before kernel can +notify userspace about it through kobject_uevent() call. If that +happens then we have a potential race between +elog_ack_store->kobject_put() and kobject_uevent which can lead to +use-after-free of a kernfs object resulting in a kernel crash. eg: + + BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb + Faulting instruction address: 0xc0000000008ff2a0 + Oops: Kernel access of bad area, sig: 11 [#1] + LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV + CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty #363 + ... + NIP kobject_uevent_env+0xa0/0x910 + LR elog_event+0x1f4/0x2d0 + Call Trace: + 0x5deadbeef0000122 (unreliable) + elog_event+0x1f4/0x2d0 + irq_thread_fn+0x4c/0xc0 + irq_thread+0x1c0/0x2b0 + kthread+0x1c4/0x1d0 + ret_from_kernel_thread+0x5c/0x6c + +This patch fixes this race by protecting the sysfs file +creation/notification by holding a reference count on kobject until we +safely send kobject_uevent(). + +The function create_elog_obj() returns the elog object which if used +by caller function will end up in use-after-free problem again. +However, the return value of create_elog_obj() function isn't being +used today and there is no need as well. Hence change it to return +void to make this fix complete. + +Fixes: 774fea1a38c6 ("powerpc/powernv: Read OPAL error log and export it through sysfs") +Cc: stable@vger.kernel.org # v3.15+ +Reported-by: Oliver O'Halloran +Signed-off-by: Mahesh Salgaonkar +Signed-off-by: Aneesh Kumar K.V +Reviewed-by: Oliver O'Halloran +Reviewed-by: Vasant Hegde +[mpe: Rework the logic to use a single return, reword comments, add oops] +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/powernv/opal-elog.c | 33 ++++++++++++++++++++++------- + 1 file changed, 26 insertions(+), 7 deletions(-) + +--- a/arch/powerpc/platforms/powernv/opal-elog.c ++++ b/arch/powerpc/platforms/powernv/opal-elog.c +@@ -183,14 +183,14 @@ static ssize_t raw_attr_read(struct file + return count; + } + +-static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type) ++static void create_elog_obj(uint64_t id, size_t size, uint64_t type) + { + struct elog_obj *elog; + int rc; + + elog = kzalloc(sizeof(*elog), GFP_KERNEL); + if (!elog) +- return NULL; ++ return; + + elog->kobj.kset = elog_kset; + +@@ -223,18 +223,37 @@ static struct elog_obj *create_elog_obj( + rc = kobject_add(&elog->kobj, NULL, "0x%llx", id); + if (rc) { + kobject_put(&elog->kobj); +- return NULL; ++ return; + } + ++ /* ++ * As soon as the sysfs file for this elog is created/activated there is ++ * a chance the opal_errd daemon (or any userspace) might read and ++ * acknowledge the elog before kobject_uevent() is called. If that ++ * happens then there is a potential race between ++ * elog_ack_store->kobject_put() and kobject_uevent() which leads to a ++ * use-after-free of a kernfs object resulting in a kernel crash. ++ * ++ * To avoid that, we need to take a reference on behalf of the bin file, ++ * so that our reference remains valid while we call kobject_uevent(). ++ * We then drop our reference before exiting the function, leaving the ++ * bin file to drop the last reference (if it hasn't already). ++ */ ++ ++ /* Take a reference for the bin file */ ++ kobject_get(&elog->kobj); + rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr); +- if (rc) { ++ if (rc == 0) { ++ kobject_uevent(&elog->kobj, KOBJ_ADD); ++ } else { ++ /* Drop the reference taken for the bin file */ + kobject_put(&elog->kobj); +- return NULL; + } + +- kobject_uevent(&elog->kobj, KOBJ_ADD); ++ /* Drop our reference */ ++ kobject_put(&elog->kobj); + +- return elog; ++ return; + } + + static irqreturn_t elog_event(int irq, void *data) diff --git a/queue-4.4/series b/queue-4.4/series index fbd5ba117fa..2dcf2f19b55 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -43,3 +43,7 @@ scsi-mptfusion-fix-null-pointer-dereferences-in-mptscsih_remove.patch btrfs-reschedule-if-necessary-when-logging-directory-items.patch vt-keyboard-simplify-vt_kdgkbsent.patch vt-keyboard-extend-func_buf_lock-to-readers.patch +dmaengine-dma-jz4780-fix-race-in-jz4780_dma_tx_status.patch +iio-gyro-itg3200-fix-timestamp-alignment-and-prevent-data-leak.patch +powerpc-powernv-elog-fix-race-while-processing-opal-error-log-event.patch +ubifs-dent-fix-some-potential-memory-leaks-while-iterating-entries.patch diff --git a/queue-4.4/ubifs-dent-fix-some-potential-memory-leaks-while-iterating-entries.patch b/queue-4.4/ubifs-dent-fix-some-potential-memory-leaks-while-iterating-entries.patch new file mode 100644 index 00000000000..4406305a8a5 --- /dev/null +++ b/queue-4.4/ubifs-dent-fix-some-potential-memory-leaks-while-iterating-entries.patch @@ -0,0 +1,33 @@ +From 58f6e78a65f1fcbf732f60a7478ccc99873ff3ba Mon Sep 17 00:00:00 2001 +From: Zhihao Cheng +Date: Mon, 1 Jun 2020 17:10:37 +0800 +Subject: ubifs: dent: Fix some potential memory leaks while iterating entries + +From: Zhihao Cheng + +commit 58f6e78a65f1fcbf732f60a7478ccc99873ff3ba upstream. + +Fix some potential memory leaks in error handling branches while +iterating dent entries. For example, function dbg_check_dir() +forgets to free pdent if it exists. + +Signed-off-by: Zhihao Cheng +Cc: +Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system") +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ubifs/debug.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/ubifs/debug.c ++++ b/fs/ubifs/debug.c +@@ -1125,6 +1125,7 @@ int dbg_check_dir(struct ubifs_info *c, + err = PTR_ERR(dent); + if (err == -ENOENT) + break; ++ kfree(pdent); + return err; + } +