From: Greg Kroah-Hartman Date: Wed, 15 Sep 2021 12:56:47 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v5.14.5~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=318d974cf548e0754708974dec0805e719baab79;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: arm64-head-avoid-over-mapping-in-map_memory.patch block-bfq-fix-bfq_set_next_ioprio_data.patch cpufreq-schedutil-use-kobject-release-method-to-free-sugov_tunables.patch crypto-public_key-fix-overflow-during-implicit-conversion.patch dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch dmaengine-imx-sdma-remove-duplicated-sdma_load_context.patch media-rc-loopback-return-number-of-emitters-rather-than-error.patch media-uvc-don-t-do-dma-on-stack.patch pinctrl-ingenic-fix-incorrect-pull-up-down-info.patch pinctrl-stmfx-fix-hazardous-u8-to-unsigned-long-cast.patch power-supply-max17042-handle-fails-of-reading-status-register.patch revert-dmaengine-imx-sdma-refine-to-load-context-only-once.patch soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch soc-aspeed-p2a-ctrl-fix-boundary-check-for-mmap.patch soc-qcom-aoss-fix-the-out-of-bound-usage-of-cooling_devs.patch tools-thermal-tmon-add-cross-compiling-support.patch vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch --- diff --git a/queue-5.4/arm64-head-avoid-over-mapping-in-map_memory.patch b/queue-5.4/arm64-head-avoid-over-mapping-in-map_memory.patch new file mode 100644 index 00000000000..b9586c6e616 --- /dev/null +++ b/queue-5.4/arm64-head-avoid-over-mapping-in-map_memory.patch @@ -0,0 +1,106 @@ +From 90268574a3e8a6b883bd802d702a2738577e1006 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Mon, 23 Aug 2021 11:12:53 +0100 +Subject: arm64: head: avoid over-mapping in map_memory + +From: Mark Rutland + +commit 90268574a3e8a6b883bd802d702a2738577e1006 upstream. + +The `compute_indices` and `populate_entries` macros operate on inclusive +bounds, and thus the `map_memory` macro which uses them also operates +on inclusive bounds. + +We pass `_end` and `_idmap_text_end` to `map_memory`, but these are +exclusive bounds, and if one of these is sufficiently aligned (as a +result of kernel configuration, physical placement, and KASLR), then: + +* In `compute_indices`, the computed `iend` will be in the page/block *after* + the final byte of the intended mapping. + +* In `populate_entries`, an unnecessary entry will be created at the end + of each level of table. At the leaf level, this entry will map up to + SWAPPER_BLOCK_SIZE bytes of physical addresses that we did not intend + to map. + +As we may map up to SWAPPER_BLOCK_SIZE bytes more than intended, we may +violate the boot protocol and map physical address past the 2MiB-aligned +end address we are permitted to map. As we map these with Normal memory +attributes, this may result in further problems depending on what these +physical addresses correspond to. + +The final entry at each level may require an additional table at that +level. As EARLY_ENTRIES() calculates an inclusive bound, we allocate +enough memory for this. + +Avoid the extraneous mapping by having map_memory convert the exclusive +end address to an inclusive end address by subtracting one, and do +likewise in EARLY_ENTRIES() when calculating the number of required +tables. For clarity, comments are updated to more clearly document which +boundaries the macros operate on. For consistency with the other +macros, the comments in map_memory are also updated to describe `vstart` +and `vend` as virtual addresses. + +Fixes: 0370b31e4845 ("arm64: Extend early page table code to allow for larger kernels") +Cc: # 4.16.x +Signed-off-by: Mark Rutland +Cc: Anshuman Khandual +Cc: Ard Biesheuvel +Cc: Steve Capper +Cc: Will Deacon +Acked-by: Will Deacon +Link: https://lore.kernel.org/r/20210823101253.55567-1-mark.rutland@arm.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/kernel-pgtable.h | 4 ++-- + arch/arm64/kernel/head.S | 11 ++++++----- + 2 files changed, 8 insertions(+), 7 deletions(-) + +--- a/arch/arm64/include/asm/kernel-pgtable.h ++++ b/arch/arm64/include/asm/kernel-pgtable.h +@@ -65,8 +65,8 @@ + #define EARLY_KASLR (0) + #endif + +-#define EARLY_ENTRIES(vstart, vend, shift) (((vend) >> (shift)) \ +- - ((vstart) >> (shift)) + 1 + EARLY_KASLR) ++#define EARLY_ENTRIES(vstart, vend, shift) \ ++ ((((vend) - 1) >> (shift)) - ((vstart) >> (shift)) + 1 + EARLY_KASLR) + + #define EARLY_PGDS(vstart, vend) (EARLY_ENTRIES(vstart, vend, PGDIR_SHIFT)) + +--- a/arch/arm64/kernel/head.S ++++ b/arch/arm64/kernel/head.S +@@ -194,7 +194,7 @@ ENDPROC(preserve_boot_args) + * to be composed of multiple pages. (This effectively scales the end index). + * + * vstart: virtual address of start of range +- * vend: virtual address of end of range ++ * vend: virtual address of end of range - we map [vstart, vend] + * shift: shift used to transform virtual address into index + * ptrs: number of entries in page table + * istart: index in table corresponding to vstart +@@ -231,17 +231,18 @@ ENDPROC(preserve_boot_args) + * + * tbl: location of page table + * rtbl: address to be used for first level page table entry (typically tbl + PAGE_SIZE) +- * vstart: start address to map +- * vend: end address to map - we map [vstart, vend] ++ * vstart: virtual address of start of range ++ * vend: virtual address of end of range - we map [vstart, vend - 1] + * flags: flags to use to map last level entries + * phys: physical address corresponding to vstart - physical memory is contiguous + * pgds: the number of pgd entries + * + * Temporaries: istart, iend, tmp, count, sv - these need to be different registers +- * Preserves: vstart, vend, flags +- * Corrupts: tbl, rtbl, istart, iend, tmp, count, sv ++ * Preserves: vstart, flags ++ * Corrupts: tbl, rtbl, vend, istart, iend, tmp, count, sv + */ + .macro map_memory, tbl, rtbl, vstart, vend, flags, phys, pgds, istart, iend, tmp, count, sv ++ sub \vend, \vend, #1 + add \rtbl, \tbl, #PAGE_SIZE + mov \sv, \rtbl + mov \count, #0 diff --git a/queue-5.4/block-bfq-fix-bfq_set_next_ioprio_data.patch b/queue-5.4/block-bfq-fix-bfq_set_next_ioprio_data.patch new file mode 100644 index 00000000000..878b622a3c8 --- /dev/null +++ b/queue-5.4/block-bfq-fix-bfq_set_next_ioprio_data.patch @@ -0,0 +1,38 @@ +From a680dd72ec336b81511e3bff48efac6dbfa563e7 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Wed, 11 Aug 2021 12:36:57 +0900 +Subject: block: bfq: fix bfq_set_next_ioprio_data() + +From: Damien Le Moal + +commit a680dd72ec336b81511e3bff48efac6dbfa563e7 upstream. + +For a request that has a priority level equal to or larger than +IOPRIO_BE_NR, bfq_set_next_ioprio_data() prints a critical warning but +defaults to setting the request new_ioprio field to IOPRIO_BE_NR. This +is not consistent with the warning and the allowed values for priority +levels. Fix this by setting the request new_ioprio field to +IOPRIO_BE_NR - 1, the lowest priority level allowed. + +Cc: +Fixes: aee69d78dec0 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler") +Signed-off-by: Damien Le Moal +Reviewed-by: Hannes Reinecke +Link: https://lore.kernel.org/r/20210811033702.368488-2-damien.lemoal@wdc.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/bfq-iosched.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/block/bfq-iosched.c ++++ b/block/bfq-iosched.c +@@ -5004,7 +5004,7 @@ bfq_set_next_ioprio_data(struct bfq_queu + if (bfqq->new_ioprio >= IOPRIO_BE_NR) { + pr_crit("bfq_set_next_ioprio_data: new_ioprio %d\n", + bfqq->new_ioprio); +- bfqq->new_ioprio = IOPRIO_BE_NR; ++ bfqq->new_ioprio = IOPRIO_BE_NR - 1; + } + + bfqq->entity.new_weight = bfq_ioprio_to_weight(bfqq->new_ioprio); diff --git a/queue-5.4/cpufreq-schedutil-use-kobject-release-method-to-free-sugov_tunables.patch b/queue-5.4/cpufreq-schedutil-use-kobject-release-method-to-free-sugov_tunables.patch new file mode 100644 index 00000000000..e700888185a --- /dev/null +++ b/queue-5.4/cpufreq-schedutil-use-kobject-release-method-to-free-sugov_tunables.patch @@ -0,0 +1,125 @@ +From e5c6b312ce3cc97e90ea159446e6bfa06645364d Mon Sep 17 00:00:00 2001 +From: Kevin Hao +Date: Thu, 5 Aug 2021 15:29:17 +0800 +Subject: cpufreq: schedutil: Use kobject release() method to free sugov_tunables + +From: Kevin Hao + +commit e5c6b312ce3cc97e90ea159446e6bfa06645364d upstream. + +The struct sugov_tunables is protected by the kobject, so we can't free +it directly. Otherwise we would get a call trace like this: + ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30 + WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 + Modules linked in: + CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507 + Hardware name: Marvell OcteonTX CN96XX board (DT) + pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) + pc : debug_print_object+0xb8/0x100 + lr : debug_print_object+0xb8/0x100 + sp : ffff80001ecaf910 + x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80 + x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000 + x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20 + x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010 + x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365 + x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69 + x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0 + x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001 + x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000 + x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000 + Call trace: + debug_print_object+0xb8/0x100 + __debug_check_no_obj_freed+0x1c0/0x230 + debug_check_no_obj_freed+0x20/0x88 + slab_free_freelist_hook+0x154/0x1c8 + kfree+0x114/0x5d0 + sugov_exit+0xbc/0xc0 + cpufreq_exit_governor+0x44/0x90 + cpufreq_set_policy+0x268/0x4a8 + store_scaling_governor+0xe0/0x128 + store+0xc0/0xf0 + sysfs_kf_write+0x54/0x80 + kernfs_fop_write_iter+0x128/0x1c0 + new_sync_write+0xf0/0x190 + vfs_write+0x2d4/0x478 + ksys_write+0x74/0x100 + __arm64_sys_write+0x24/0x30 + invoke_syscall.constprop.0+0x54/0xe0 + do_el0_svc+0x64/0x158 + el0_svc+0x2c/0xb0 + el0t_64_sync_handler+0xb0/0xb8 + el0t_64_sync+0x198/0x19c + irq event stamp: 5518 + hardirqs last enabled at (5517): [] console_unlock+0x554/0x6c8 + hardirqs last disabled at (5518): [] el1_dbg+0x28/0xa0 + softirqs last enabled at (5504): [] __do_softirq+0x4d0/0x6c0 + softirqs last disabled at (5483): [] irq_exit+0x1b0/0x1b8 + +So split the original sugov_tunables_free() into two functions, +sugov_clear_global_tunables() is just used to clear the global_tunables +and the new sugov_tunables_free() is used as kobj_type::release to +release the sugov_tunables safely. + +Fixes: 9bdcb44e391d ("cpufreq: schedutil: New governor based on scheduler utilization data") +Cc: 4.7+ # 4.7+ +Signed-off-by: Kevin Hao +Acked-by: Viresh Kumar +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + kernel/sched/cpufreq_schedutil.c | 16 +++++++++++----- + 1 file changed, 11 insertions(+), 5 deletions(-) + +--- a/kernel/sched/cpufreq_schedutil.c ++++ b/kernel/sched/cpufreq_schedutil.c +@@ -624,9 +624,17 @@ static struct attribute *sugov_attrs[] = + }; + ATTRIBUTE_GROUPS(sugov); + ++static void sugov_tunables_free(struct kobject *kobj) ++{ ++ struct gov_attr_set *attr_set = container_of(kobj, struct gov_attr_set, kobj); ++ ++ kfree(to_sugov_tunables(attr_set)); ++} ++ + static struct kobj_type sugov_tunables_ktype = { + .default_groups = sugov_groups, + .sysfs_ops = &governor_sysfs_ops, ++ .release = &sugov_tunables_free, + }; + + /********************** cpufreq governor interface *********************/ +@@ -726,12 +734,10 @@ static struct sugov_tunables *sugov_tuna + return tunables; + } + +-static void sugov_tunables_free(struct sugov_tunables *tunables) ++static void sugov_clear_global_tunables(void) + { + if (!have_governor_per_policy()) + global_tunables = NULL; +- +- kfree(tunables); + } + + static int sugov_init(struct cpufreq_policy *policy) +@@ -794,7 +800,7 @@ out: + fail: + kobject_put(&tunables->attr_set.kobj); + policy->governor_data = NULL; +- sugov_tunables_free(tunables); ++ sugov_clear_global_tunables(); + + stop_kthread: + sugov_kthread_stop(sg_policy); +@@ -821,7 +827,7 @@ static void sugov_exit(struct cpufreq_po + count = gov_attr_set_put(&tunables->attr_set, &sg_policy->tunables_hook); + policy->governor_data = NULL; + if (!count) +- sugov_tunables_free(tunables); ++ sugov_clear_global_tunables(); + + mutex_unlock(&global_tunables_lock); + diff --git a/queue-5.4/crypto-public_key-fix-overflow-during-implicit-conversion.patch b/queue-5.4/crypto-public_key-fix-overflow-during-implicit-conversion.patch new file mode 100644 index 00000000000..ebd1c0f2145 --- /dev/null +++ b/queue-5.4/crypto-public_key-fix-overflow-during-implicit-conversion.patch @@ -0,0 +1,70 @@ +From f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a Mon Sep 17 00:00:00 2001 +From: zhenwei pi +Date: Thu, 19 Aug 2021 20:37:10 +0800 +Subject: crypto: public_key: fix overflow during implicit conversion + +From: zhenwei pi + +commit f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a upstream. + +Hit kernel warning like this, it can be reproduced by verifying 256 +bytes datafile by keyctl command, run script: +RAWDATA=rawdata +SIGDATA=sigdata + +modprobe pkcs8_key_parser + +rm -rf *.der *.pem *.pfx +rm -rf $RAWDATA +dd if=/dev/random of=$RAWDATA bs=256 count=1 + +openssl req -nodes -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ + -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=xx.com/emailAddress=yy@xx.com" + +KEY_ID=`openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER | keyctl \ + padd asymmetric 123 @s` + +keyctl pkey_sign $KEY_ID 0 $RAWDATA enc=pkcs1 hash=sha1 > $SIGDATA +keyctl pkey_verify $KEY_ID 0 $RAWDATA $SIGDATA enc=pkcs1 hash=sha1 + +Then the kernel reports: + WARNING: CPU: 5 PID: 344556 at crypto/rsa-pkcs1pad.c:540 + pkcs1pad_verify+0x160/0x190 + ... + Call Trace: + public_key_verify_signature+0x282/0x380 + ? software_key_query+0x12d/0x180 + ? keyctl_pkey_params_get+0xd6/0x130 + asymmetric_key_verify_signature+0x66/0x80 + keyctl_pkey_verify+0xa5/0x100 + do_syscall_64+0x35/0xb0 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +The reason of this issue, in function 'asymmetric_key_verify_signature': +'.digest_size(u8) = params->in_len(u32)' leads overflow of an u8 value, +so use u32 instead of u8 for digest_size field. And reorder struct +public_key_signature, it saves 8 bytes on a 64-bit machine. + +Cc: stable@vger.kernel.org +Signed-off-by: zhenwei pi +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman +--- + include/crypto/public_key.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/include/crypto/public_key.h ++++ b/include/crypto/public_key.h +@@ -38,9 +38,9 @@ extern void public_key_free(struct publi + struct public_key_signature { + struct asymmetric_key_id *auth_ids[2]; + u8 *s; /* Signature */ +- u32 s_size; /* Number of bytes in signature */ + u8 *digest; +- u8 digest_size; /* Number of bytes in digest */ ++ u32 s_size; /* Number of bytes in signature */ ++ u32 digest_size; /* Number of bytes in digest */ + const char *pkey_algo; + const char *hash_algo; + const char *encoding; diff --git a/queue-5.4/dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch b/queue-5.4/dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch new file mode 100644 index 00000000000..998835870b6 --- /dev/null +++ b/queue-5.4/dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch @@ -0,0 +1,128 @@ +From 528b16bfc3ae5f11638e71b3b63a81f9999df727 Mon Sep 17 00:00:00 2001 +From: Arne Welzel +Date: Sat, 14 Aug 2021 00:40:38 +0200 +Subject: dm crypt: Avoid percpu_counter spinlock contention in crypt_page_alloc() + +From: Arne Welzel + +commit 528b16bfc3ae5f11638e71b3b63a81f9999df727 upstream. + +On systems with many cores using dm-crypt, heavy spinlock contention in +percpu_counter_compare() can be observed when the page allocation limit +for a given device is reached or close to be reached. This is due +to percpu_counter_compare() taking a spinlock to compute an exact +result on potentially many CPUs at the same time. + +Switch to non-exact comparison of allocated and allowed pages by using +the value returned by percpu_counter_read_positive() to avoid taking +the percpu_counter spinlock. + +This may over/under estimate the actual number of allocated pages by at +most (batch-1) * num_online_cpus(). + +Currently, batch is bounded by 32. The system on which this issue was +first observed has 256 CPUs and 512GB of RAM. With a 4k page size, this +change may over/under estimate by 31MB. With ~10G (2%) allowed dm-crypt +allocations, this seems an acceptable error. Certainly preferred over +running into the spinlock contention. + +This behavior was reproduced on an EC2 c5.24xlarge instance with 96 CPUs +and 192GB RAM as follows, but can be provoked on systems with less CPUs +as well. + + * Disable swap + * Tune vm settings to promote regular writeback + $ echo 50 > /proc/sys/vm/dirty_expire_centisecs + $ echo 25 > /proc/sys/vm/dirty_writeback_centisecs + $ echo $((128 * 1024 * 1024)) > /proc/sys/vm/dirty_background_bytes + + * Create 8 dmcrypt devices based on files on a tmpfs + * Create and mount an ext4 filesystem on each crypt devices + * Run stress-ng --hdd 8 within one of above filesystems + +Total %system usage collected from sysstat goes to ~35%. Write throughput +on the underlying loop device is ~2GB/s. perf profiling an individual +kworker kcryptd thread shows the following profile, indicating spinlock +contention in percpu_counter_compare(): + + 99.98% 0.00% kworker/u193:46 [kernel.kallsyms] [k] ret_from_fork + | + --ret_from_fork + kthread + worker_thread + | + --99.92%--process_one_work + | + |--80.52%--kcryptd_crypt + | | + | |--62.58%--mempool_alloc + | | | + | | --62.24%--crypt_page_alloc + | | | + | | --61.51%--__percpu_counter_compare + | | | + | | --61.34%--__percpu_counter_sum + | | | + | | |--58.68%--_raw_spin_lock_irqsave + | | | | + | | | --58.30%--native_queued_spin_lock_slowpath + | | | + | | --0.69%--cpumask_next + | | | + | | --0.51%--_find_next_bit + | | + | |--10.61%--crypt_convert + | | | + | | |--6.05%--xts_crypt + ... + +After applying this patch and running the same test, %system usage is +lowered to ~7% and write throughput on the loop device increases +to ~2.7GB/s. perf report shows mempool_alloc() as ~8% rather than ~62% +in the profile and not hitting the percpu_counter() spinlock anymore. + + |--8.15%--mempool_alloc + | | + | |--3.93%--crypt_page_alloc + | | | + | | --3.75%--__alloc_pages + | | | + | | --3.62%--get_page_from_freelist + | | | + | | --3.22%--rmqueue_bulk + | | | + | | --2.59%--_raw_spin_lock + | | | + | | --2.57%--native_queued_spin_lock_slowpath + | | + | --3.05%--_raw_spin_lock_irqsave + | | + | --2.49%--native_queued_spin_lock_slowpath + +Suggested-by: DJ Gregor +Reviewed-by: Mikulas Patocka +Signed-off-by: Arne Welzel +Fixes: 5059353df86e ("dm crypt: limit the number of allocated pages") +Cc: stable@vger.kernel.org +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-crypt.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/md/dm-crypt.c ++++ b/drivers/md/dm-crypt.c +@@ -2092,7 +2092,12 @@ static void *crypt_page_alloc(gfp_t gfp_ + struct crypt_config *cc = pool_data; + struct page *page; + +- if (unlikely(percpu_counter_compare(&cc->n_allocated_pages, dm_crypt_pages_per_client) >= 0) && ++ /* ++ * Note, percpu_counter_read_positive() may over (and under) estimate ++ * the current usage by at most (batch - 1) * num_online_cpus() pages, ++ * but avoids potential spinlock contention of an exact result. ++ */ ++ if (unlikely(percpu_counter_read_positive(&cc->n_allocated_pages) >= dm_crypt_pages_per_client) && + likely(gfp_mask & __GFP_NORETRY)) + return NULL; + diff --git a/queue-5.4/dmaengine-imx-sdma-remove-duplicated-sdma_load_context.patch b/queue-5.4/dmaengine-imx-sdma-remove-duplicated-sdma_load_context.patch new file mode 100644 index 00000000000..e189da2b2a9 --- /dev/null +++ b/queue-5.4/dmaengine-imx-sdma-remove-duplicated-sdma_load_context.patch @@ -0,0 +1,44 @@ +From e555a03b112838883fdd8185d613c35d043732f2 Mon Sep 17 00:00:00 2001 +From: Robin Gong +Date: Wed, 14 Jul 2021 18:20:44 +0800 +Subject: dmaengine: imx-sdma: remove duplicated sdma_load_context + +From: Robin Gong + +commit e555a03b112838883fdd8185d613c35d043732f2 upstream. + +Since sdma_transfer_init() will do sdma_load_context before any +sdma transfer, no need once more in sdma_config_channel(). + +Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") +Cc: +Signed-off-by: Robin Gong +Acked-by: Vinod Koul +Tested-by: Richard Leitner +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma/imx-sdma.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +--- a/drivers/dma/imx-sdma.c ++++ b/drivers/dma/imx-sdma.c +@@ -1134,7 +1134,6 @@ static void sdma_set_watermarklevel_for_ + static int sdma_config_channel(struct dma_chan *chan) + { + struct sdma_channel *sdmac = to_sdma_chan(chan); +- int ret; + + sdma_disable_channel(chan); + +@@ -1174,9 +1173,7 @@ static int sdma_config_channel(struct dm + sdmac->watermark_level = 0; /* FIXME: M3_BASE_ADDRESS */ + } + +- ret = sdma_load_context(sdmac); +- +- return ret; ++ return 0; + } + + static int sdma_set_channel_priority(struct sdma_channel *sdmac, diff --git a/queue-5.4/media-rc-loopback-return-number-of-emitters-rather-than-error.patch b/queue-5.4/media-rc-loopback-return-number-of-emitters-rather-than-error.patch new file mode 100644 index 00000000000..fc19a508579 --- /dev/null +++ b/queue-5.4/media-rc-loopback-return-number-of-emitters-rather-than-error.patch @@ -0,0 +1,31 @@ +From 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Sat, 3 Jul 2021 15:37:17 +0200 +Subject: media: rc-loopback: return number of emitters rather than error + +From: Sean Young + +commit 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 upstream. + +The LIRC_SET_TRANSMITTER_MASK ioctl should return the number of emitters +if an invalid list was set. + +Cc: stable@vger.kernel.org +Signed-off-by: Sean Young +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/rc-loopback.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/media/rc/rc-loopback.c ++++ b/drivers/media/rc/rc-loopback.c +@@ -42,7 +42,7 @@ static int loop_set_tx_mask(struct rc_de + + if ((mask & (RXMASK_REGULAR | RXMASK_LEARNING)) != mask) { + dprintk("invalid tx mask: %u\n", mask); +- return -EINVAL; ++ return 2; + } + + dprintk("setting tx mask: %u\n", mask); diff --git a/queue-5.4/media-uvc-don-t-do-dma-on-stack.patch b/queue-5.4/media-uvc-don-t-do-dma-on-stack.patch new file mode 100644 index 00000000000..8a8e7d9632e --- /dev/null +++ b/queue-5.4/media-uvc-don-t-do-dma-on-stack.patch @@ -0,0 +1,96 @@ +From 1a10d7fdb6d0e235e9d230916244cc2769d3f170 Mon Sep 17 00:00:00 2001 +From: Mauro Carvalho Chehab +Date: Thu, 17 Jun 2021 14:33:29 +0200 +Subject: media: uvc: don't do DMA on stack + +From: Mauro Carvalho Chehab + +commit 1a10d7fdb6d0e235e9d230916244cc2769d3f170 upstream. + +As warned by smatch: + drivers/media/usb/uvc/uvc_v4l2.c:911 uvc_ioctl_g_input() error: doing dma on the stack (&i) + drivers/media/usb/uvc/uvc_v4l2.c:943 uvc_ioctl_s_input() error: doing dma on the stack (&i) + +those two functions call uvc_query_ctrl passing a pointer to +a data at the DMA stack. those are used to send URBs via +usb_control_msg(). Using DMA stack is not supported and should +not work anymore on modern Linux versions. + +So, use a kmalloc'ed buffer. + +Cc: stable@vger.kernel.org # Kernel 4.9 and upper +Reviewed-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/usb/uvc/uvc_v4l2.c | 34 +++++++++++++++++++++++----------- + 1 file changed, 23 insertions(+), 11 deletions(-) + +--- a/drivers/media/usb/uvc/uvc_v4l2.c ++++ b/drivers/media/usb/uvc/uvc_v4l2.c +@@ -894,8 +894,8 @@ static int uvc_ioctl_g_input(struct file + { + struct uvc_fh *handle = fh; + struct uvc_video_chain *chain = handle->chain; ++ u8 *buf; + int ret; +- u8 i; + + if (chain->selector == NULL || + (chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) { +@@ -903,22 +903,27 @@ static int uvc_ioctl_g_input(struct file + return 0; + } + ++ buf = kmalloc(1, GFP_KERNEL); ++ if (!buf) ++ return -ENOMEM; ++ + ret = uvc_query_ctrl(chain->dev, UVC_GET_CUR, chain->selector->id, + chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL, +- &i, 1); +- if (ret < 0) +- return ret; ++ buf, 1); ++ if (!ret) ++ *input = *buf - 1; + +- *input = i - 1; +- return 0; ++ kfree(buf); ++ ++ return ret; + } + + static int uvc_ioctl_s_input(struct file *file, void *fh, unsigned int input) + { + struct uvc_fh *handle = fh; + struct uvc_video_chain *chain = handle->chain; ++ u8 *buf; + int ret; +- u32 i; + + ret = uvc_acquire_privileges(handle); + if (ret < 0) +@@ -934,10 +939,17 @@ static int uvc_ioctl_s_input(struct file + if (input >= chain->selector->bNrInPins) + return -EINVAL; + +- i = input + 1; +- return uvc_query_ctrl(chain->dev, UVC_SET_CUR, chain->selector->id, +- chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL, +- &i, 1); ++ buf = kmalloc(1, GFP_KERNEL); ++ if (!buf) ++ return -ENOMEM; ++ ++ *buf = input + 1; ++ ret = uvc_query_ctrl(chain->dev, UVC_SET_CUR, chain->selector->id, ++ chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL, ++ buf, 1); ++ kfree(buf); ++ ++ return ret; + } + + static int uvc_ioctl_queryctrl(struct file *file, void *fh, diff --git a/queue-5.4/pinctrl-ingenic-fix-incorrect-pull-up-down-info.patch b/queue-5.4/pinctrl-ingenic-fix-incorrect-pull-up-down-info.patch new file mode 100644 index 00000000000..67c5cbe12f8 --- /dev/null +++ b/queue-5.4/pinctrl-ingenic-fix-incorrect-pull-up-down-info.patch @@ -0,0 +1,52 @@ +From d5e931403942b3af39212960c2592b5ba741b2bf Mon Sep 17 00:00:00 2001 +From: Paul Cercueil +Date: Sat, 17 Jul 2021 18:48:34 +0100 +Subject: pinctrl: ingenic: Fix incorrect pull up/down info +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Paul Cercueil + +commit d5e931403942b3af39212960c2592b5ba741b2bf upstream. + +Fix the pull up/down info for both the JZ4760 and JZ4770 SoCs, as the +previous values sometimes contradicted what's written in the programming +manual. + +Fixes: b5c23aa46537 ("pinctrl: add a pinctrl driver for the Ingenic jz47xx SoCs") +Cc: # v4.12 +Signed-off-by: Paul Cercueil +Tested-by: 周琰杰 (Zhou Yanjie) +Link: https://lore.kernel.org/r/20210717174836.14776-1-paul@crapouillou.net +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/pinctrl-ingenic.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/pinctrl/pinctrl-ingenic.c ++++ b/drivers/pinctrl/pinctrl-ingenic.c +@@ -348,7 +348,7 @@ static const struct ingenic_chip_info jz + }; + + static const u32 jz4760_pull_ups[6] = { +- 0xffffffff, 0xfffcf3ff, 0xffffffff, 0xffffcfff, 0xfffffb7c, 0xfffff00f, ++ 0xffffffff, 0xfffcf3ff, 0xffffffff, 0xffffcfff, 0xfffffb7c, 0x0000000f, + }; + + static const u32 jz4760_pull_downs[6] = { +@@ -611,11 +611,11 @@ static const struct ingenic_chip_info jz + }; + + static const u32 jz4770_pull_ups[6] = { +- 0x3fffffff, 0xfff0030c, 0xffffffff, 0xffff4fff, 0xfffffb7c, 0xffa7f00f, ++ 0x3fffffff, 0xfff0f3fc, 0xffffffff, 0xffff4fff, 0xfffffb7c, 0x0024f00f, + }; + + static const u32 jz4770_pull_downs[6] = { +- 0x00000000, 0x000f0c03, 0x00000000, 0x0000b000, 0x00000483, 0x00580ff0, ++ 0x00000000, 0x000f0c03, 0x00000000, 0x0000b000, 0x00000483, 0x005b0ff0, + }; + + static int jz4770_uart0_data_pins[] = { 0xa0, 0xa3, }; diff --git a/queue-5.4/pinctrl-stmfx-fix-hazardous-u8-to-unsigned-long-cast.patch b/queue-5.4/pinctrl-stmfx-fix-hazardous-u8-to-unsigned-long-cast.patch new file mode 100644 index 00000000000..0f4cb10cdd4 --- /dev/null +++ b/queue-5.4/pinctrl-stmfx-fix-hazardous-u8-to-unsigned-long-cast.patch @@ -0,0 +1,57 @@ +From 1b73e588f47397dee6e4bdfd953e0306c60b5fe5 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Sun, 25 Jul 2021 19:08:30 +0100 +Subject: pinctrl: stmfx: Fix hazardous u8[] to unsigned long cast + +From: Marc Zyngier + +commit 1b73e588f47397dee6e4bdfd953e0306c60b5fe5 upstream. + +Casting a small array of u8 to an unsigned long is *never* OK: + +- it does funny thing when the array size is less than that of a long, + as it accesses random places in the stack +- it makes everything even more fun with a BE kernel + +Fix this by building the unsigned long used as a bitmap byte by byte, +in a way that works across endianess and has no undefined behaviours. + +An extra BUILD_BUG_ON() catches the unlikely case where the array +would be larger than a single unsigned long. + +Fixes: 1490d9f841b1 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver") +Signed-off-by: Marc Zyngier +Cc: stable@vger.kernel.org +Cc: Amelie Delaunay +Cc: Linus Walleij +Cc: Maxime Coquelin +Cc: Alexandre Torgue +Link: https://lore.kernel.org/r/20210725180830.250218-1-maz@kernel.org +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/pinctrl-stmfx.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/pinctrl/pinctrl-stmfx.c ++++ b/drivers/pinctrl/pinctrl-stmfx.c +@@ -540,7 +540,7 @@ static irqreturn_t stmfx_pinctrl_irq_thr + u8 pending[NR_GPIO_REGS]; + u8 src[NR_GPIO_REGS] = {0, 0, 0}; + unsigned long n, status; +- int ret; ++ int i, ret; + + ret = regmap_bulk_read(pctl->stmfx->map, STMFX_REG_IRQ_GPI_PENDING, + &pending, NR_GPIO_REGS); +@@ -550,7 +550,9 @@ static irqreturn_t stmfx_pinctrl_irq_thr + regmap_bulk_write(pctl->stmfx->map, STMFX_REG_IRQ_GPI_SRC, + src, NR_GPIO_REGS); + +- status = *(unsigned long *)pending; ++ BUILD_BUG_ON(NR_GPIO_REGS > sizeof(status)); ++ for (i = 0, status = 0; i < NR_GPIO_REGS; i++) ++ status |= (unsigned long)pending[i] << (i * 8); + for_each_set_bit(n, &status, gc->ngpio) { + handle_nested_irq(irq_find_mapping(gc->irq.domain, n)); + stmfx_pinctrl_irq_toggle_trigger(pctl, n); diff --git a/queue-5.4/power-supply-max17042-handle-fails-of-reading-status-register.patch b/queue-5.4/power-supply-max17042-handle-fails-of-reading-status-register.patch new file mode 100644 index 00000000000..554197d4948 --- /dev/null +++ b/queue-5.4/power-supply-max17042-handle-fails-of-reading-status-register.patch @@ -0,0 +1,43 @@ +From 54784ffa5b267f57161eb8fbb811499f22a0a0bf Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Mon, 16 Aug 2021 10:27:14 +0200 +Subject: power: supply: max17042: handle fails of reading status register + +From: Krzysztof Kozlowski + +commit 54784ffa5b267f57161eb8fbb811499f22a0a0bf upstream. + +Reading status register can fail in the interrupt handler. In such +case, the regmap_read() will not store anything useful under passed +'val' variable and random stack value will be used to determine type of +interrupt. + +Handle the regmap_read() failure to avoid handling interrupt type and +triggering changed power supply event based on random stack value. + +Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers") +Cc: +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Hans de Goede +Signed-off-by: Sebastian Reichel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/power/supply/max17042_battery.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/power/supply/max17042_battery.c ++++ b/drivers/power/supply/max17042_battery.c +@@ -842,8 +842,12 @@ static irqreturn_t max17042_thread_handl + { + struct max17042_chip *chip = dev; + u32 val; ++ int ret; ++ ++ ret = regmap_read(chip->regmap, MAX17042_STATUS, &val); ++ if (ret) ++ return IRQ_HANDLED; + +- regmap_read(chip->regmap, MAX17042_STATUS, &val); + if ((val & STATUS_INTR_SOCMIN_BIT) || + (val & STATUS_INTR_SOCMAX_BIT)) { + dev_info(&chip->client->dev, "SOC threshold INTR\n"); diff --git a/queue-5.4/revert-dmaengine-imx-sdma-refine-to-load-context-only-once.patch b/queue-5.4/revert-dmaengine-imx-sdma-refine-to-load-context-only-once.patch new file mode 100644 index 00000000000..2230cf1f522 --- /dev/null +++ b/queue-5.4/revert-dmaengine-imx-sdma-refine-to-load-context-only-once.patch @@ -0,0 +1,68 @@ +From 8592f02464d52776c5cfae4627c6413b0ae7602d Mon Sep 17 00:00:00 2001 +From: Robin Gong +Date: Wed, 14 Jul 2021 18:20:43 +0800 +Subject: Revert "dmaengine: imx-sdma: refine to load context only once" + +From: Robin Gong + +commit 8592f02464d52776c5cfae4627c6413b0ae7602d upstream. + +This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because +in spi-imx case, burst length may be changed dynamically. + +Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") +Cc: +Signed-off-by: Robin Gong +Acked-by: Sascha Hauer +Tested-by: Richard Leitner +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma/imx-sdma.c | 8 -------- + 1 file changed, 8 deletions(-) + +--- a/drivers/dma/imx-sdma.c ++++ b/drivers/dma/imx-sdma.c +@@ -377,7 +377,6 @@ struct sdma_channel { + unsigned long watermark_level; + u32 shp_addr, per_addr; + enum dma_status status; +- bool context_loaded; + struct imx_dma_data data; + struct work_struct terminate_worker; + }; +@@ -988,9 +987,6 @@ static int sdma_load_context(struct sdma + int ret; + unsigned long flags; + +- if (sdmac->context_loaded) +- return 0; +- + if (sdmac->direction == DMA_DEV_TO_MEM) + load_address = sdmac->pc_from_device; + else if (sdmac->direction == DMA_DEV_TO_DEV) +@@ -1033,8 +1029,6 @@ static int sdma_load_context(struct sdma + + spin_unlock_irqrestore(&sdma->channel_0_lock, flags); + +- sdmac->context_loaded = true; +- + return ret; + } + +@@ -1074,7 +1068,6 @@ static void sdma_channel_terminate_work( + sdmac->desc = NULL; + spin_unlock_irqrestore(&sdmac->vc.lock, flags); + vchan_dma_desc_free_list(&sdmac->vc, &head); +- sdmac->context_loaded = false; + } + + static int sdma_disable_channel_async(struct dma_chan *chan) +@@ -1335,7 +1328,6 @@ static void sdma_free_chan_resources(str + + sdmac->event_id0 = 0; + sdmac->event_id1 = 0; +- sdmac->context_loaded = false; + + sdma_set_channel_priority(sdmac, 0); + diff --git a/queue-5.4/series b/queue-5.4/series index cf8b548e5a1..7b58eb2451c 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -8,3 +8,20 @@ powerpc-perf-hv-gpci-fix-counter-value-parsing.patch xen-fix-setting-of-max_pfn-in-shared_info.patch include-linux-list.h-add-a-macro-to-test-if-entry-is-pointing-to-the-head.patch 9p-xen-fix-end-of-loop-tests-for-list_for_each_entry.patch +tools-thermal-tmon-add-cross-compiling-support.patch +pinctrl-stmfx-fix-hazardous-u8-to-unsigned-long-cast.patch +pinctrl-ingenic-fix-incorrect-pull-up-down-info.patch +soc-qcom-aoss-fix-the-out-of-bound-usage-of-cooling_devs.patch +soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch +soc-aspeed-p2a-ctrl-fix-boundary-check-for-mmap.patch +arm64-head-avoid-over-mapping-in-map_memory.patch +crypto-public_key-fix-overflow-during-implicit-conversion.patch +block-bfq-fix-bfq_set_next_ioprio_data.patch +power-supply-max17042-handle-fails-of-reading-status-register.patch +cpufreq-schedutil-use-kobject-release-method-to-free-sugov_tunables.patch +dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch +vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch +media-uvc-don-t-do-dma-on-stack.patch +media-rc-loopback-return-number-of-emitters-rather-than-error.patch +revert-dmaengine-imx-sdma-refine-to-load-context-only-once.patch +dmaengine-imx-sdma-remove-duplicated-sdma_load_context.patch diff --git a/queue-5.4/soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch b/queue-5.4/soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch new file mode 100644 index 00000000000..24c5103bac2 --- /dev/null +++ b/queue-5.4/soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch @@ -0,0 +1,38 @@ +From b49a0e69a7b1a68c8d3f64097d06dabb770fec96 Mon Sep 17 00:00:00 2001 +From: Iwona Winiarska +Date: Wed, 4 Aug 2021 01:48:18 +0200 +Subject: soc: aspeed: lpc-ctrl: Fix boundary check for mmap + +From: Iwona Winiarska + +commit b49a0e69a7b1a68c8d3f64097d06dabb770fec96 upstream. + +The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one +side of the comparison, and uses resource address (rather than just the +resource size) on the other side of the comparison. +This can allow malicious userspace to easily bypass the boundary check and +map pages that are located outside memory-region reserved by the driver. + +Fixes: 6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver") +Cc: stable@vger.kernel.org +Signed-off-by: Iwona Winiarska +Reviewed-by: Andrew Jeffery +Tested-by: Andrew Jeffery +Reviewed-by: Joel Stanley +Signed-off-by: Joel Stanley +Signed-off-by: Greg Kroah-Hartman +--- + drivers/soc/aspeed/aspeed-lpc-ctrl.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c ++++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c +@@ -46,7 +46,7 @@ static int aspeed_lpc_ctrl_mmap(struct f + unsigned long vsize = vma->vm_end - vma->vm_start; + pgprot_t prot = vma->vm_page_prot; + +- if (vma->vm_pgoff + vsize > lpc_ctrl->mem_base + lpc_ctrl->mem_size) ++ if (vma->vm_pgoff + vma_pages(vma) > lpc_ctrl->mem_size >> PAGE_SHIFT) + return -EINVAL; + + /* ast2400/2500 AHB accesses are not cache coherent */ diff --git a/queue-5.4/soc-aspeed-p2a-ctrl-fix-boundary-check-for-mmap.patch b/queue-5.4/soc-aspeed-p2a-ctrl-fix-boundary-check-for-mmap.patch new file mode 100644 index 00000000000..b229867dc3f --- /dev/null +++ b/queue-5.4/soc-aspeed-p2a-ctrl-fix-boundary-check-for-mmap.patch @@ -0,0 +1,38 @@ +From 8b07e990fb254fcbaa919616ac77f981cb48c73d Mon Sep 17 00:00:00 2001 +From: Iwona Winiarska +Date: Wed, 4 Aug 2021 01:48:19 +0200 +Subject: soc: aspeed: p2a-ctrl: Fix boundary check for mmap + +From: Iwona Winiarska + +commit 8b07e990fb254fcbaa919616ac77f981cb48c73d upstream. + +The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one +side of the comparison, and uses resource address (rather than just the +resource size) on the other side of the comparison. +This can allow malicious userspace to easily bypass the boundary check and +map pages that are located outside memory-region reserved by the driver. + +Fixes: 01c60dcea9f7 ("drivers/misc: Add Aspeed P2A control driver") +Cc: stable@vger.kernel.org +Signed-off-by: Iwona Winiarska +Reviewed-by: Andrew Jeffery +Tested-by: Andrew Jeffery +Reviewed-by: Joel Stanley +Signed-off-by: Joel Stanley +Signed-off-by: Greg Kroah-Hartman +--- + drivers/soc/aspeed/aspeed-p2a-ctrl.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/soc/aspeed/aspeed-p2a-ctrl.c ++++ b/drivers/soc/aspeed/aspeed-p2a-ctrl.c +@@ -110,7 +110,7 @@ static int aspeed_p2a_mmap(struct file * + vsize = vma->vm_end - vma->vm_start; + prot = vma->vm_page_prot; + +- if (vma->vm_pgoff + vsize > ctrl->mem_base + ctrl->mem_size) ++ if (vma->vm_pgoff + vma_pages(vma) > ctrl->mem_size >> PAGE_SHIFT) + return -EINVAL; + + /* ast2400/2500 AHB accesses are not cache coherent */ diff --git a/queue-5.4/soc-qcom-aoss-fix-the-out-of-bound-usage-of-cooling_devs.patch b/queue-5.4/soc-qcom-aoss-fix-the-out-of-bound-usage-of-cooling_devs.patch new file mode 100644 index 00000000000..439d35b8619 --- /dev/null +++ b/queue-5.4/soc-qcom-aoss-fix-the-out-of-bound-usage-of-cooling_devs.patch @@ -0,0 +1,66 @@ +From a89f355e469dcda129c2522be4fdba00c1c74c83 Mon Sep 17 00:00:00 2001 +From: Manivannan Sadhasivam +Date: Tue, 29 Jun 2021 21:02:49 +0530 +Subject: soc: qcom: aoss: Fix the out of bound usage of cooling_devs + +From: Manivannan Sadhasivam + +commit a89f355e469dcda129c2522be4fdba00c1c74c83 upstream. + +In "qmp_cooling_devices_register", the count value is initially +QMP_NUM_COOLING_RESOURCES, which is 2. Based on the initial count value, +the memory for cooling_devs is allocated. Then while calling the +"qmp_cooling_device_add" function, count value is post-incremented for +each child node. + +This makes the out of bound access to the cooling_dev array. Fix it by +passing the QMP_NUM_COOLING_RESOURCES definition to devm_kzalloc() and +initializing the count to 0. + +While at it, let's also free the memory allocated to cooling_dev if no +cooling device is found in DT and during unroll phase. + +Cc: stable@vger.kernel.org # 5.4 +Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") +Signed-off-by: Manivannan Sadhasivam +Link: https://lore.kernel.org/r/20210629153249.73428-1-manivannan.sadhasivam@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/soc/qcom/qcom_aoss.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/soc/qcom/qcom_aoss.c ++++ b/drivers/soc/qcom/qcom_aoss.c +@@ -472,12 +472,12 @@ static int qmp_cooling_device_add(struct + static int qmp_cooling_devices_register(struct qmp *qmp) + { + struct device_node *np, *child; +- int count = QMP_NUM_COOLING_RESOURCES; ++ int count = 0; + int ret; + + np = qmp->dev->of_node; + +- qmp->cooling_devs = devm_kcalloc(qmp->dev, count, ++ qmp->cooling_devs = devm_kcalloc(qmp->dev, QMP_NUM_COOLING_RESOURCES, + sizeof(*qmp->cooling_devs), + GFP_KERNEL); + +@@ -493,12 +493,16 @@ static int qmp_cooling_devices_register( + goto unroll; + } + ++ if (!count) ++ devm_kfree(qmp->dev, qmp->cooling_devs); ++ + return 0; + + unroll: + while (--count >= 0) + thermal_cooling_device_unregister + (qmp->cooling_devs[count].cdev); ++ devm_kfree(qmp->dev, qmp->cooling_devs); + + return ret; + } diff --git a/queue-5.4/tools-thermal-tmon-add-cross-compiling-support.patch b/queue-5.4/tools-thermal-tmon-add-cross-compiling-support.patch new file mode 100644 index 00000000000..e538ce4cde4 --- /dev/null +++ b/queue-5.4/tools-thermal-tmon-add-cross-compiling-support.patch @@ -0,0 +1,34 @@ +From b5f7912bb604b47a0fe024560488a7556dce8ee7 Mon Sep 17 00:00:00 2001 +From: Rolf Eike Beer +Date: Fri, 30 Jul 2021 13:51:54 +0200 +Subject: tools/thermal/tmon: Add cross compiling support + +From: Rolf Eike Beer + +commit b5f7912bb604b47a0fe024560488a7556dce8ee7 upstream. + +Default to prefixed pkg-config when crosscompiling, this matches what +other parts of the tools/ directory already do. + +[dlezcano] : Reworked description + +Signed-off-by: Rolf Eike Beer +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Lezcano +Link: https://lore.kernel.org/r/31302992.qZodDJZGDc@devpool47 +Signed-off-by: Greg Kroah-Hartman +--- + tools/thermal/tmon/Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/thermal/tmon/Makefile ++++ b/tools/thermal/tmon/Makefile +@@ -10,7 +10,7 @@ override CFLAGS+= $(call cc-option,-O3,- + # Add "-fstack-protector" only if toolchain supports it. + override CFLAGS+= $(call cc-option,-fstack-protector-strong) + CC?= $(CROSS_COMPILE)gcc +-PKG_CONFIG?= pkg-config ++PKG_CONFIG?= $(CROSS_COMPILE)pkg-config + + override CFLAGS+=-D VERSION=\"$(VERSION)\" + LDFLAGS+= diff --git a/queue-5.4/vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch b/queue-5.4/vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch new file mode 100644 index 00000000000..f33f2df35d1 --- /dev/null +++ b/queue-5.4/vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch @@ -0,0 +1,79 @@ +From a30dc6cf0dc51419021550152e435736aaef8799 Mon Sep 17 00:00:00 2001 +From: Wang Hai +Date: Wed, 18 Aug 2021 20:48:45 +0800 +Subject: VMCI: fix NULL pointer dereference when unmapping queue pair + +From: Wang Hai + +commit a30dc6cf0dc51419021550152e435736aaef8799 upstream. + +I got a NULL pointer dereference report when doing fuzz test: + +Call Trace: + qp_release_pages+0xae/0x130 + qp_host_unregister_user_memory.isra.25+0x2d/0x80 + vmci_qp_broker_unmap+0x191/0x320 + ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 + vmci_host_unlocked_ioctl+0x59f/0xd50 + ? do_vfs_ioctl+0x14b/0xa10 + ? tomoyo_file_ioctl+0x28/0x30 + ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 + __x64_sys_ioctl+0xea/0x120 + do_syscall_64+0x34/0xb0 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +When a queue pair is created by the following call, it will not +register the user memory if the page_store is NULL, and the +entry->state will be set to VMCIQPB_CREATED_NO_MEM. + +vmci_host_unlocked_ioctl + vmci_host_do_alloc_queuepair + vmci_qp_broker_alloc + qp_broker_alloc + qp_broker_create // set entry->state = VMCIQPB_CREATED_NO_MEM; + +When unmapping this queue pair, qp_host_unregister_user_memory() will +be called to unregister the non-existent user memory, which will +result in a null pointer reference. It will also change +VMCIQPB_CREATED_NO_MEM to VMCIQPB_CREATED_MEM, which should not be +present in this operation. + +Only when the qp broker has mem, it can unregister the user +memory when unmapping the qp broker. + +Only when the qp broker has no mem, it can register the user +memory when mapping the qp broker. + +Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") +Cc: stable +Reported-by: Hulk Robot +Reviewed-by: Jorgen Hansen +Signed-off-by: Wang Hai +Link: https://lore.kernel.org/r/20210818124845.488312-1-wanghai38@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/vmw_vmci/vmci_queue_pair.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c ++++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c +@@ -2238,7 +2238,8 @@ int vmci_qp_broker_map(struct vmci_handl + + result = VMCI_SUCCESS; + +- if (context_id != VMCI_HOST_CONTEXT_ID) { ++ if (context_id != VMCI_HOST_CONTEXT_ID && ++ !QPBROKERSTATE_HAS_MEM(entry)) { + struct vmci_qp_page_store page_store; + + page_store.pages = guest_mem; +@@ -2345,7 +2346,8 @@ int vmci_qp_broker_unmap(struct vmci_han + goto out; + } + +- if (context_id != VMCI_HOST_CONTEXT_ID) { ++ if (context_id != VMCI_HOST_CONTEXT_ID && ++ QPBROKERSTATE_HAS_MEM(entry)) { + qp_acquire_queue_mutex(entry->produce_q); + result = qp_save_headers(entry); + if (result < VMCI_SUCCESS)