- Linux-stable-mirror - lists.linaro.org

[RFC please help] membarrier: Rewrite sync_core_before_usermode()

by Andy Lutomirski

The old sync_core_before_usermode() comments said that a non-icache-syncing return-to-usermode instruction is x86-specific and that all other architectures automatically notice cross-modified code on return to userspace. Based on my general understanding of how CPUs work and based on my atttempt to read the ARM manual, this is not true at all. In fact, x86 seems to be a bit of an anomaly in the other direction: x86's IRET is unusually heavyweight for a return-to-usermode instruction. So let's drop any pretense that we can have a generic way implementation behind membarrier's SYNC_CORE flush and require all architectures that opt in to supply their own. This means x86, arm64, and powerpc for now. Let's also rename the function from sync_core_before_usermode() to membarrier_sync_core_before_usermode() because the precise flushing details may very well be specific to membarrier, and even the concept of "sync_core" in the kernel is mostly an x86-ism. I admit that I'm rather surprised that the code worked at all on arm64, and I'm suspicious that it has never been very well tested. My apologies for not reviewing this more carefully in the first place. Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Paul Mackerras <paulus(a)samba.org> Cc: linuxppc-dev(a)lists.ozlabs.org Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: linux-arm-kernel(a)lists.infradead.org Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: x86(a)kernel.org Cc: stable(a)vger.kernel.org Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski <luto(a)kernel.org> --- Hi arm64 and powerpc people- This is part of a series here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/f… Before I send out the whole series, I'm hoping that some arm64 and powerpc people can help me verify that I did this patch right. Once I get some feedback on this patch, I'll send out the whole pile. And once *that's* done, I'll start giving the mm lazy stuff some serious thought. The x86 part is already fixed in Linus' tree. Thanks, Andy arch/arm64/include/asm/sync_core.h | 21 +++++++++++++++++++++ arch/powerpc/include/asm/sync_core.h | 20 ++++++++++++++++++++ arch/x86/Kconfig | 1 - arch/x86/include/asm/sync_core.h | 7 +++---- include/linux/sched/mm.h | 1 - include/linux/sync_core.h | 21 --------------------- init/Kconfig | 3 --- kernel/sched/membarrier.c | 15 +++++++++++---- 8 files changed, 55 insertions(+), 34 deletions(-) create mode 100644 arch/arm64/include/asm/sync_core.h create mode 100644 arch/powerpc/include/asm/sync_core.h delete mode 100644 include/linux/sync_core.h diff --git a/arch/arm64/include/asm/sync_core.h b/arch/arm64/include/asm/sync_core.h new file mode 100644 index 000000000000..5be4531caabd --- /dev/null +++ b/arch/arm64/include/asm/sync_core.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_ARM64_SYNC_CORE_H +#define _ASM_ARM64_SYNC_CORE_H + +#include <asm/barrier.h> + +/* + * Ensure that the CPU notices any instruction changes before the next time + * it returns to usermode. + */ +static inline void membarrier_sync_core_before_usermode(void) +{ + /* + * XXX: is this enough or do we need a DMB first to make sure that + * writes from other CPUs become visible to this CPU? We have an + * smp_mb() already, but that's not quite the same thing. + */ + isb(); +} + +#endif /* _ASM_ARM64_SYNC_CORE_H */ diff --git a/arch/powerpc/include/asm/sync_core.h b/arch/powerpc/include/asm/sync_core.h new file mode 100644 index 000000000000..71dfbe7794e5 --- /dev/null +++ b/arch/powerpc/include/asm/sync_core.h @@ -0,0 +1,20 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_POWERPC_SYNC_CORE_H +#define _ASM_POWERPC_SYNC_CORE_H + +#include <asm/barrier.h> + +/* + * Ensure that the CPU notices any instruction changes before the next time + * it returns to usermode. + */ +static inline void membarrier_sync_core_before_usermode(void) +{ + /* + * XXX: I know basically nothing about powerpc cache management. + * Is this correct? + */ + isync(); +} + +#endif /* _ASM_POWERPC_SYNC_CORE_H */ diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b5137cc5b7b4..895f70fd4a61 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -81,7 +81,6 @@ config X86 select ARCH_HAS_SET_DIRECT_MAP select ARCH_HAS_STRICT_KERNEL_RWX select ARCH_HAS_STRICT_MODULE_RWX - select ARCH_HAS_SYNC_CORE_BEFORE_USERMODE select ARCH_HAS_SYSCALL_WRAPPER select ARCH_HAS_UBSAN_SANITIZE_ALL select ARCH_HAS_DEBUG_WX diff --git a/arch/x86/include/asm/sync_core.h b/arch/x86/include/asm/sync_core.h index ab7382f92aff..c665b453969a 100644 --- a/arch/x86/include/asm/sync_core.h +++ b/arch/x86/include/asm/sync_core.h @@ -89,11 +89,10 @@ static inline void sync_core(void) } /* - * Ensure that a core serializing instruction is issued before returning - * to user-mode. x86 implements return to user-space through sysexit, - * sysrel, and sysretq, which are not core serializing. + * Ensure that the CPU notices any instruction changes before the next time + * it returns to usermode. */ -static inline void sync_core_before_usermode(void) +static inline void membarrier_sync_core_before_usermode(void) { /* With PTI, we unconditionally serialize before running user code. */ if (static_cpu_has(X86_FEATURE_PTI)) diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h index 48640db6ca86..81ba47910a73 100644 --- a/include/linux/sched/mm.h +++ b/include/linux/sched/mm.h @@ -7,7 +7,6 @@ #include <linux/sched.h> #include <linux/mm_types.h> #include <linux/gfp.h> -#include <linux/sync_core.h> /* * Routines for handling mm_structs diff --git a/include/linux/sync_core.h b/include/linux/sync_core.h deleted file mode 100644 index 013da4b8b327..000000000000 --- a/include/linux/sync_core.h +++ /dev/null @@ -1,21 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef _LINUX_SYNC_CORE_H -#define _LINUX_SYNC_CORE_H - -#ifdef CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE -#include <asm/sync_core.h> -#else -/* - * This is a dummy sync_core_before_usermode() implementation that can be used - * on all architectures which return to user-space through core serializing - * instructions. - * If your architecture returns to user-space through non-core-serializing - * instructions, you need to write your own functions. - */ -static inline void sync_core_before_usermode(void) -{ -} -#endif - -#endif /* _LINUX_SYNC_CORE_H */ - diff --git a/init/Kconfig b/init/Kconfig index c9446911cf41..eb9772078cd4 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -2334,9 +2334,6 @@ source "kernel/Kconfig.locks" config ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE bool -config ARCH_HAS_SYNC_CORE_BEFORE_USERMODE - bool - # It may be useful for an architecture to override the definitions of the # SYSCALL_DEFINE() and __SYSCALL_DEFINEx() macros in <linux/syscalls.h> # and the COMPAT_ variants in <linux/compat.h>, in particular to use a diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c index b3a82d7635da..db4945e1ec94 100644 --- a/kernel/sched/membarrier.c +++ b/kernel/sched/membarrier.c @@ -5,6 +5,9 @@ * membarrier system call */ #include "sched.h" +#ifdef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE +#include <asm/sync_core.h> +#endif /* * The basic principle behind the regular memory barrier mode of membarrier() @@ -221,6 +224,7 @@ static void ipi_mb(void *info) smp_mb(); /* IPIs should be serializing but paranoid. */ } +#ifdef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE static void ipi_sync_core(void *info) { /* @@ -230,13 +234,14 @@ static void ipi_sync_core(void *info) * the big comment at the top of this file. * * A sync_core() would provide this guarantee, but - * sync_core_before_usermode() might end up being deferred until - * after membarrier()'s smp_mb(). + * membarrier_sync_core_before_usermode() might end up being deferred + * until after membarrier()'s smp_mb(). */ smp_mb(); /* IPIs should be serializing but paranoid. */ - sync_core_before_usermode(); + membarrier_sync_core_before_usermode(); } +#endif static void ipi_rseq(void *info) { @@ -368,12 +373,14 @@ static int membarrier_private_expedited(int flags, int cpu_id) smp_call_func_t ipi_func = ipi_mb; if (flags == MEMBARRIER_FLAG_SYNC_CORE) { - if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE)) +#ifndef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE return -EINVAL; +#else if (!(atomic_read(&mm->membarrier_state) & MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE_READY)) return -EPERM; ipi_func = ipi_sync_core; +#endif } else if (flags == MEMBARRIER_FLAG_RSEQ) { if (!IS_ENABLED(CONFIG_RSEQ)) return -EINVAL; -- 2.29.2

4 years, 7 months

9
33
0 0

[PATCH 1/2] x86/mm/sme: Fix definition of PMD_FLAGS_DEC_WP

by Arvind Sankar

The PAT bit is in different locations for 4k and 2M/1G page table entries. Add a definition for _PAGE_LARGE_CACHE_MASK to represent the three caching bits (PWT, PCD, PAT), similar to _PAGE_CACHE_MASK for 4k pages, and use it in the definition of PMD_FLAGS_DEC_WP to get the correct PAT index for write-protected pages. Signed-off-by: Arvind Sankar <nivedita(a)alum.mit.edu> Fixes: 6ebcb060713f ("x86/mm: Add support to encrypt the kernel in-place") Tested-by: Tom Lendacky <thomas.lendacky(a)amd.com> Cc: stable(a)vger.kernel.org --- arch/x86/include/asm/pgtable_types.h | 1 + arch/x86/mm/mem_encrypt_identity.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index 816b31c68550..394757ee030a 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -155,6 +155,7 @@ enum page_cache_mode { #define _PAGE_ENC (_AT(pteval_t, sme_me_mask)) #define _PAGE_CACHE_MASK (_PAGE_PWT | _PAGE_PCD | _PAGE_PAT) +#define _PAGE_LARGE_CACHE_MASK (_PAGE_PWT | _PAGE_PCD | _PAGE_PAT_LARGE) #define _PAGE_NOCACHE (cachemode2protval(_PAGE_CACHE_MODE_UC)) #define _PAGE_CACHE_WP (cachemode2protval(_PAGE_CACHE_MODE_WP)) diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c index 733b983f3a89..6c5eb6f3f14f 100644 --- a/arch/x86/mm/mem_encrypt_identity.c +++ b/arch/x86/mm/mem_encrypt_identity.c @@ -45,8 +45,8 @@ #define PMD_FLAGS_LARGE (__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL) #define PMD_FLAGS_DEC PMD_FLAGS_LARGE -#define PMD_FLAGS_DEC_WP ((PMD_FLAGS_DEC & ~_PAGE_CACHE_MASK) | \ - (_PAGE_PAT | _PAGE_PWT)) +#define PMD_FLAGS_DEC_WP ((PMD_FLAGS_DEC & ~_PAGE_LARGE_CACHE_MASK) | \ + (_PAGE_PAT_LARGE | _PAGE_PWT)) #define PMD_FLAGS_ENC (PMD_FLAGS_LARGE | _PAGE_ENC) -- 2.26.2

4 years, 7 months

3
4
0 0

FAILED: patch "[PATCH] iio:magnetometer:mag3110: Fix alignment and data leak issues." failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 89deb1334252ea4a8491d47654811e28b0790364 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:37 +0100 Subject: [PATCH] iio:magnetometer:mag3110: Fix alignment and data leak issues. 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 an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it. Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver") Reported-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org diff --git a/drivers/iio/magnetometer/mag3110.c b/drivers/iio/magnetometer/mag3110.c index 838b13c8bb3d..c96415a1aead 100644 --- a/drivers/iio/magnetometer/mag3110.c +++ b/drivers/iio/magnetometer/mag3110.c @@ -56,6 +56,12 @@ struct mag3110_data { int sleep_val; struct regulator *vdd_reg; struct regulator *vddio_reg; + /* Ensure natural alignment of timestamp */ + struct { + __be16 channels[3]; + u8 temperature; + s64 ts __aligned(8); + } scan; }; static int mag3110_request(struct mag3110_data *data) @@ -387,10 +393,9 @@ static irqreturn_t mag3110_trigger_handler(int irq, void *p) struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct mag3110_data *data = iio_priv(indio_dev); - u8 buffer[16]; /* 3 16-bit channels + 1 byte temp + padding + ts */ int ret; - ret = mag3110_read(data, (__be16 *) buffer); + ret = mag3110_read(data, data->scan.channels); if (ret < 0) goto done; @@ -399,10 +404,10 @@ static irqreturn_t mag3110_trigger_handler(int irq, void *p) MAG3110_DIE_TEMP); if (ret < 0) goto done; - buffer[6] = ret; + data->scan.temperature = ret; } - iio_push_to_buffers_with_timestamp(indio_dev, buffer, + iio_push_to_buffers_with_timestamp(indio_dev, &data->scan, iio_get_time_ns(indio_dev)); done:

4 years, 7 months

2
1
0 0

FAILED: patch "[PATCH] iio:magnetometer:mag3110: Fix alignment and data leak issues." failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 89deb1334252ea4a8491d47654811e28b0790364 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:37 +0100 Subject: [PATCH] iio:magnetometer:mag3110: Fix alignment and data leak issues. 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 an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it. Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver") Reported-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org diff --git a/drivers/iio/magnetometer/mag3110.c b/drivers/iio/magnetometer/mag3110.c index 838b13c8bb3d..c96415a1aead 100644 --- a/drivers/iio/magnetometer/mag3110.c +++ b/drivers/iio/magnetometer/mag3110.c @@ -56,6 +56,12 @@ struct mag3110_data { int sleep_val; struct regulator *vdd_reg; struct regulator *vddio_reg; + /* Ensure natural alignment of timestamp */ + struct { + __be16 channels[3]; + u8 temperature; + s64 ts __aligned(8); + } scan; }; static int mag3110_request(struct mag3110_data *data) @@ -387,10 +393,9 @@ static irqreturn_t mag3110_trigger_handler(int irq, void *p) struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct mag3110_data *data = iio_priv(indio_dev); - u8 buffer[16]; /* 3 16-bit channels + 1 byte temp + padding + ts */ int ret; - ret = mag3110_read(data, (__be16 *) buffer); + ret = mag3110_read(data, data->scan.channels); if (ret < 0) goto done; @@ -399,10 +404,10 @@ static irqreturn_t mag3110_trigger_handler(int irq, void *p) MAG3110_DIE_TEMP); if (ret < 0) goto done; - buffer[6] = ret; + data->scan.temperature = ret; } - iio_push_to_buffers_with_timestamp(indio_dev, buffer, + iio_push_to_buffers_with_timestamp(indio_dev, &data->scan, iio_get_time_ns(indio_dev)); done:

4 years, 7 months

2
1
0 0

[PATCH 0/4] sched/idle: Fix missing need_resched() checks after rcu_idle_enter()

by Frederic Weisbecker

With Paul, we've been thinking that the idle loop wasn't twisted enough yet to deserve 2020. rcutorture, after some recent parameter changes, has been complaining about a hung task. It appears that rcu_idle_enter() may wake up a NOCB kthread but this happens after the last generic need_resched() check. Some cpuidle drivers fix it by chance but many others don't. Here is a proposed bunch of fixes. I will need to also fix the rcu_user_enter() case, likely using irq_work, since nohz_full requires irq work to support self IPI. Also more generally, this raise the question of local task wake_up() under disabled interrupts. When a wake up occurs in a preempt disabled section, it gets handled by the outer preempt_enable() call. There is no similar mechanism when a wake up occurs with interrupts disabled. I guess it is assumed to be handled, at worst, in the next tick. But a local irq work would provide instant preemption once IRQs are re-enabled. Of course this would only make sense in CONFIG_PREEMPTION, and when the tick is disabled... git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git sched/idle HEAD: f2fa6e4a070c1535b9edc9ee097167fd2b15d235 Thanks, Frederic --- Frederic Weisbecker (4): sched/idle: Fix missing need_resched() check after rcu_idle_enter() cpuidle: Fix missing need_resched() check after rcu_idle_enter() ARM: imx6q: Fix missing need_resched() check after rcu_idle_enter() ACPI: processor: Fix missing need_resched() check after rcu_idle_enter() arch/arm/mach-imx/cpuidle-imx6q.c | 7 ++++++- drivers/acpi/processor_idle.c | 10 ++++++++-- drivers/cpuidle/cpuidle.c | 33 +++++++++++++++++++++++++-------- kernel/sched/idle.c | 18 ++++++++++++------ 4 files changed, 51 insertions(+), 17 deletions(-)

4 years, 7 months

4
10
0 0

FAILED: patch "[PATCH] iio:imu:bmi160: Fix alignment and data leak issues" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 7b6b51234df6cd8b04fe736b0b89c25612d896b8 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:39 +0100 Subject: [PATCH] iio:imu:bmi160: Fix alignment and data leak issues 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 an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading. Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160") Reported-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: Daniel Baluta <daniel.baluta(a)gmail.com> Cc: Daniel Baluta <daniel.baluta(a)oss.nxp.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h index a82e040bd109..32c2ea2d7112 100644 --- a/drivers/iio/imu/bmi160/bmi160.h +++ b/drivers/iio/imu/bmi160/bmi160.h @@ -10,6 +10,13 @@ struct bmi160_data { struct iio_trigger *trig; struct regulator_bulk_data supplies[2]; struct iio_mount_matrix orientation; + /* + * Ensure natural alignment for timestamp if present. + * Max length needed: 2 * 3 channels + 4 bytes padding + 8 byte ts. + * If fewer channels are enabled, less space may be needed, as + * long as the timestamp is still aligned to 8 bytes. + */ + __le16 buf[12] __aligned(8); }; extern const struct regmap_config bmi160_regmap_config; diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c index c8e131c29043..290b5ef83f77 100644 --- a/drivers/iio/imu/bmi160/bmi160_core.c +++ b/drivers/iio/imu/bmi160/bmi160_core.c @@ -427,8 +427,6 @@ static irqreturn_t bmi160_trigger_handler(int irq, void *p) struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct bmi160_data *data = iio_priv(indio_dev); - __le16 buf[12]; - /* 2 sens x 3 axis x __le16 + 2 x __le16 pad + 4 x __le16 tstamp */ int i, ret, j = 0, base = BMI160_REG_DATA_MAGN_XOUT_L; __le16 sample; @@ -438,10 +436,10 @@ static irqreturn_t bmi160_trigger_handler(int irq, void *p) &sample, sizeof(sample)); if (ret) goto done; - buf[j++] = sample; + data->buf[j++] = sample; } - iio_push_to_buffers_with_timestamp(indio_dev, buf, pf->timestamp); + iio_push_to_buffers_with_timestamp(indio_dev, data->buf, pf->timestamp); done: iio_trigger_notify_done(indio_dev->trig); return IRQ_HANDLED;

4 years, 7 months

2
1
0 0

FAILED: patch "[PATCH] iio:imu:bmi160: Fix alignment and data leak issues" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 7b6b51234df6cd8b04fe736b0b89c25612d896b8 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:39 +0100 Subject: [PATCH] iio:imu:bmi160: Fix alignment and data leak issues 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 an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading. Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160") Reported-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: Daniel Baluta <daniel.baluta(a)gmail.com> Cc: Daniel Baluta <daniel.baluta(a)oss.nxp.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h index a82e040bd109..32c2ea2d7112 100644 --- a/drivers/iio/imu/bmi160/bmi160.h +++ b/drivers/iio/imu/bmi160/bmi160.h @@ -10,6 +10,13 @@ struct bmi160_data { struct iio_trigger *trig; struct regulator_bulk_data supplies[2]; struct iio_mount_matrix orientation; + /* + * Ensure natural alignment for timestamp if present. + * Max length needed: 2 * 3 channels + 4 bytes padding + 8 byte ts. + * If fewer channels are enabled, less space may be needed, as + * long as the timestamp is still aligned to 8 bytes. + */ + __le16 buf[12] __aligned(8); }; extern const struct regmap_config bmi160_regmap_config; diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c index c8e131c29043..290b5ef83f77 100644 --- a/drivers/iio/imu/bmi160/bmi160_core.c +++ b/drivers/iio/imu/bmi160/bmi160_core.c @@ -427,8 +427,6 @@ static irqreturn_t bmi160_trigger_handler(int irq, void *p) struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct bmi160_data *data = iio_priv(indio_dev); - __le16 buf[12]; - /* 2 sens x 3 axis x __le16 + 2 x __le16 pad + 4 x __le16 tstamp */ int i, ret, j = 0, base = BMI160_REG_DATA_MAGN_XOUT_L; __le16 sample; @@ -438,10 +436,10 @@ static irqreturn_t bmi160_trigger_handler(int irq, void *p) &sample, sizeof(sample)); if (ret) goto done; - buf[j++] = sample; + data->buf[j++] = sample; } - iio_push_to_buffers_with_timestamp(indio_dev, buf, pf->timestamp); + iio_push_to_buffers_with_timestamp(indio_dev, data->buf, pf->timestamp); done: iio_trigger_notify_done(indio_dev->trig); return IRQ_HANDLED;

4 years, 7 months

2
1
0 0

FAILED: patch "[PATCH] iio:imu:bmi160: Fix alignment and data leak issues" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 7b6b51234df6cd8b04fe736b0b89c25612d896b8 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:39 +0100 Subject: [PATCH] iio:imu:bmi160: Fix alignment and data leak issues 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 an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading. Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160") Reported-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: Daniel Baluta <daniel.baluta(a)gmail.com> Cc: Daniel Baluta <daniel.baluta(a)oss.nxp.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h index a82e040bd109..32c2ea2d7112 100644 --- a/drivers/iio/imu/bmi160/bmi160.h +++ b/drivers/iio/imu/bmi160/bmi160.h @@ -10,6 +10,13 @@ struct bmi160_data { struct iio_trigger *trig; struct regulator_bulk_data supplies[2]; struct iio_mount_matrix orientation; + /* + * Ensure natural alignment for timestamp if present. + * Max length needed: 2 * 3 channels + 4 bytes padding + 8 byte ts. + * If fewer channels are enabled, less space may be needed, as + * long as the timestamp is still aligned to 8 bytes. + */ + __le16 buf[12] __aligned(8); }; extern const struct regmap_config bmi160_regmap_config; diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c index c8e131c29043..290b5ef83f77 100644 --- a/drivers/iio/imu/bmi160/bmi160_core.c +++ b/drivers/iio/imu/bmi160/bmi160_core.c @@ -427,8 +427,6 @@ static irqreturn_t bmi160_trigger_handler(int irq, void *p) struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct bmi160_data *data = iio_priv(indio_dev); - __le16 buf[12]; - /* 2 sens x 3 axis x __le16 + 2 x __le16 pad + 4 x __le16 tstamp */ int i, ret, j = 0, base = BMI160_REG_DATA_MAGN_XOUT_L; __le16 sample; @@ -438,10 +436,10 @@ static irqreturn_t bmi160_trigger_handler(int irq, void *p) &sample, sizeof(sample)); if (ret) goto done; - buf[j++] = sample; + data->buf[j++] = sample; } - iio_push_to_buffers_with_timestamp(indio_dev, buf, pf->timestamp); + iio_push_to_buffers_with_timestamp(indio_dev, data->buf, pf->timestamp); done: iio_trigger_notify_done(indio_dev->trig); return IRQ_HANDLED;

4 years, 7 months

2
1
0 0

[PATCH] block: fix use-after-free in disk_part_iter_next

by Ming Lei

Make sure that bdgrab() is done on the 'block_device' instance before referring to it for avoiding use-after-free. Cc: <stable(a)vger.kernel.org> Reported-by: syzbot+825f0f9657d4e528046e(a)syzkaller.appspotmail.com Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- block/genhd.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/block/genhd.c b/block/genhd.c index b84b8671e627..2df3c5b1c9c8 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -244,15 +244,18 @@ struct block_device *disk_part_iter_next(struct disk_part_iter *piter) part = rcu_dereference(ptbl->part[piter->idx]); if (!part) continue; + piter->part = bdgrab(part); + if (!piter->part) + continue; if (!bdev_nr_sectors(part) && !(piter->flags & DISK_PITER_INCL_EMPTY) && !(piter->flags & DISK_PITER_INCL_EMPTY_PART0 && - piter->idx == 0)) + piter->idx == 0)) { + bdput(piter->part); + piter->part = NULL; continue; + } - piter->part = bdgrab(part); - if (!piter->part) - continue; piter->idx += inc; break; } -- 2.28.0

4 years, 7 months

3
2
0 0

stable-rc/linux-4.19.y baseline: 170 runs, 7 regressions (v4.19.164-30-g40a2b34effd3)

by kernelci.org bot

stable-rc/linux-4.19.y baseline: 170 runs, 7 regressions (v4.19.164-30-g40a2b34effd3) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ meson-gxl-s905x-khadas-vim | arm64 | lab-baylibre | gcc-8 | defconfig | 1 panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-collabora | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-linaro-lkft | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.16… Test: baseline Tree: stable-rc Branch: linux-4.19.y Describe: v4.19.164-30-g40a2b34effd3 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 40a2b34effd3cc1b96cad6ef78e18879d4145c09 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ meson-gxl-s905x-khadas-vim | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/5ff4752d1738d167ffc94cb9 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5ff4752d1738d167ffc94cba failing since 0 day (last pass: v4.19.163, first fail: v4.19.164-36-g32d98dff91dae) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/5ff47419b9ee8382a6c94cc5 Results: 4 PASS, 1 FAIL, 0 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/5ff47419b9ee8382a6c94cca failing since 55 days (last pass: v4.19.155-42-g97cf958a4cd1, first fail: v4.19.157) 2 lines 2021-01-05 14:13:40.532000+00:00 kern :emerg : lock: emif_lock+0x0/0xffffed34 [emif], .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 2021-01-05 14:13:40.545000+00:00 <8>[ 22.889739] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=emerg RESULT=fail UNITS=lines MEASUREMENT=2> platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/5ff472c95dfa9b4bbec94ce2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5ff472c95dfa9b4bbec94ce3 failing since 48 days (last pass: v4.19.157-26-ga8e7fec1fea1, first fail: v4.19.157-102-g1d674327c1b7) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/5ff472ddee0e9a2cb3c94ce0 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5ff472ddee0e9a2cb3c94ce1 failing since 48 days (last pass: v4.19.157-26-ga8e7fec1fea1, first fail: v4.19.157-102-g1d674327c1b7) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/5ff472dbee0e9a2cb3c94cdb Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5ff472dbee0e9a2cb3c94cdc failing since 48 days (last pass: v4.19.157-26-ga8e7fec1fea1, first fail: v4.19.157-102-g1d674327c1b7) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-collabora | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/5ff47294907c33f442c94d01 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5ff47294907c33f442c94d02 failing since 48 days (last pass: v4.19.157-26-ga8e7fec1fea1, first fail: v4.19.157-102-g1d674327c1b7) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+-----------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-linaro-lkft | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/5ff4735f60ede0eb12c94cea Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.164-30-g40a2b34e… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5ff4735f60ede0eb12c94ceb failing since 48 days (last pass: v4.19.157-26-ga8e7fec1fea1, first fail: v4.19.157-102-g1d674327c1b7)

4 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror