* Patch "metag/uaccess: Check access_ok in strncpy_from_user" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: james.hogan, gregkh, viro; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
metag/uaccess: Check access_ok in strncpy_from_user
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
metag-uaccess-check-access_ok-in-strncpy_from_user.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 3a158a62da0673db918b53ac1440845a5b64fd90 Mon Sep 17 00:00:00 2001
From: James Hogan <james.hogan@imgtec.com>
Date: Tue, 2 May 2017 19:41:06 +0100
Subject: metag/uaccess: Check access_ok in strncpy_from_user
From: James Hogan <james.hogan@imgtec.com>
commit 3a158a62da0673db918b53ac1440845a5b64fd90 upstream.
The metag implementation of strncpy_from_user() doesn't validate the src
pointer, which could allow reading of arbitrary kernel memory. Add a
short access_ok() check to prevent that.
Its still possible for it to read across the user/kernel boundary, but
it will invariably reach a NUL character after only 9 bytes, leaking
only a static kernel address being loaded into D0Re0 at the beginning of
__start, which is acceptable for the immediate fix.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/metag/include/asm/uaccess.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -194,8 +194,13 @@ do {
extern long __must_check __strncpy_from_user(char *dst, const char __user *src,
long count);
-#define strncpy_from_user(dst, src, count) __strncpy_from_user(dst, src, count)
-
+static inline long
+strncpy_from_user(char *dst, const char __user *src, long count)
+{
+ if (!access_ok(VERIFY_READ, src, 1))
+ return -EFAULT;
+ return __strncpy_from_user(dst, src, count);
+}
/*
* Return the size of a string (including the ending 0)
*
Patches currently in stable-queue which might be from james.hogan@imgtec.com are
queue-4.11/metag-uaccess-check-access_ok-in-strncpy_from_user.patch
queue-4.11/metag-uaccess-fix-access_ok.patch
^ permalink raw reply
* Patch "KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: marc.zyngier, cdall, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kvm-arm-arm64-vgic-v2-do-not-use-active-pending-state-for-a-hw-interrupt.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From ddf42d068f8802de122bb7efdfcb3179336053f1 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue, 2 May 2017 14:30:39 +0100
Subject: KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt
From: Marc Zyngier <marc.zyngier@arm.com>
commit ddf42d068f8802de122bb7efdfcb3179336053f1 upstream.
When an interrupt is injected with the HW bit set (indicating that
deactivation should be propagated to the physical distributor),
special care must be taken so that we never mark the corresponding
LR with the Active+Pending state (as the pending state is kept in
the physycal distributor).
Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
virt/kvm/arm/vgic/vgic-v2.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -181,6 +181,13 @@ void vgic_v2_populate_lr(struct kvm_vcpu
if (irq->hw) {
val |= GICH_LR_HW;
val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
+ /*
+ * Never set pending+active on a HW interrupt, as the
+ * pending state is kept at the physical distributor
+ * level.
+ */
+ if (irq->active && irq_is_pending(irq))
+ val &= ~GICH_LR_PENDING_BIT;
} else {
if (irq->config == VGIC_CONFIG_LEVEL)
val |= GICH_LR_EOI;
Patches currently in stable-queue which might be from marc.zyngier@arm.com are
queue-4.11/arm64-kvm-do-not-use-stack-protector-to-compile-el2-code.patch
queue-4.11/arm-kvm-do-not-use-stack-protector-to-compile-hyp-code.patch
queue-4.11/kvm-arm-arm64-vgic-v3-do-not-use-active-pending-state-for-a-hw-interrupt.patch
queue-4.11/kvm-arm-arm64-vgic-v2-do-not-use-active-pending-state-for-a-hw-interrupt.patch
^ permalink raw reply
* Patch "KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: marc.zyngier, cdall, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kvm-arm-arm64-vgic-v3-do-not-use-active-pending-state-for-a-hw-interrupt.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 3d6e77ad1489650afa20da92bb589c8778baa8da Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue, 2 May 2017 14:30:40 +0100
Subject: KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt
From: Marc Zyngier <marc.zyngier@arm.com>
commit 3d6e77ad1489650afa20da92bb589c8778baa8da upstream.
When an interrupt is injected with the HW bit set (indicating that
deactivation should be propagated to the physical distributor),
special care must be taken so that we never mark the corresponding
LR with the Active+Pending state (as the pending state is kept in
the physycal distributor).
Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
virt/kvm/arm/vgic/vgic-v3.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -149,6 +149,13 @@ void vgic_v3_populate_lr(struct kvm_vcpu
if (irq->hw) {
val |= ICH_LR_HW;
val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
+ /*
+ * Never set pending+active on a HW interrupt, as the
+ * pending state is kept at the physical distributor
+ * level.
+ */
+ if (irq->active && irq_is_pending(irq))
+ val &= ~ICH_LR_PENDING_BIT;
} else {
if (irq->config == VGIC_CONFIG_LEVEL)
val |= ICH_LR_EOI;
Patches currently in stable-queue which might be from marc.zyngier@arm.com are
queue-4.11/arm64-kvm-do-not-use-stack-protector-to-compile-el2-code.patch
queue-4.11/arm-kvm-do-not-use-stack-protector-to-compile-hyp-code.patch
queue-4.11/kvm-arm-arm64-vgic-v3-do-not-use-active-pending-state-for-a-hw-interrupt.patch
queue-4.11/kvm-arm-arm64-vgic-v2-do-not-use-active-pending-state-for-a-hw-interrupt.patch
^ permalink raw reply
* Patch "iommu/vt-d: Flush the IOTLB to get rid of the initial kdump mappings" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: karahmed, aliguori, dwmw2, dwmw, gregkh, joro, jroedel
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iommu/vt-d: Flush the IOTLB to get rid of the initial kdump mappings
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iommu-vt-d-flush-the-iotlb-to-get-rid-of-the-initial-kdump-mappings.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From f73a7eee900e95404b61408a23a1df5c5811704c Mon Sep 17 00:00:00 2001
From: KarimAllah Ahmed <karahmed@amazon.de>
Date: Fri, 5 May 2017 11:39:59 -0700
Subject: iommu/vt-d: Flush the IOTLB to get rid of the initial kdump mappings
From: KarimAllah Ahmed <karahmed@amazon.de>
commit f73a7eee900e95404b61408a23a1df5c5811704c upstream.
Ever since commit 091d42e43d ("iommu/vt-d: Copy translation tables from
old kernel") the kdump kernel copies the IOMMU context tables from the
previous kernel. Each device mappings will be destroyed once the driver
for the respective device takes over.
This unfortunately breaks the workflow of mapping and unmapping a new
context to the IOMMU. The mapping function assumes that either:
1) Unmapping did the proper IOMMU flushing and it only ever flush if the
IOMMU unit supports caching invalid entries.
2) The system just booted and the initialization code took care of
flushing all IOMMU caches.
This assumption is not true for the kdump kernel since the context
tables have been copied from the previous kernel and translations could
have been cached ever since. So make sure to flush the IOTLB as well
when we destroy these old copied mappings.
Cc: Joerg Roedel <joro@8bytes.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Anthony Liguori <aliguori@amazon.com>
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Fixes: 091d42e43d ("iommu/vt-d: Copy translation tables from old kernel")
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/intel-iommu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2050,11 +2050,14 @@ static int domain_context_mapping_one(st
if (context_copied(context)) {
u16 did_old = context_domain_id(context);
- if (did_old >= 0 && did_old < cap_ndoms(iommu->cap))
+ if (did_old >= 0 && did_old < cap_ndoms(iommu->cap)) {
iommu->flush.flush_context(iommu, did_old,
(((u16)bus) << 8) | devfn,
DMA_CCMD_MASK_NOBIT,
DMA_CCMD_DEVICE_INVL);
+ iommu->flush.flush_iotlb(iommu, did_old, 0, 0,
+ DMA_TLB_DSI_FLUSH);
+ }
}
pgd = domain->pgd;
Patches currently in stable-queue which might be from karahmed@amazon.de are
queue-4.11/iommu-vt-d-flush-the-iotlb-to-get-rid-of-the-initial-kdump-mappings.patch
^ permalink raw reply
* Patch "cpuidle: check dev before usage in cpuidle_use_deepest_state()" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: fei.li, andriy.shevchenko, fengx.shi, gregkh, rafael.j.wysocki
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
cpuidle: check dev before usage in cpuidle_use_deepest_state()
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
cpuidle-check-dev-before-usage-in-cpuidle_use_deepest_state.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 41dc750ea67f317c0deedde713d1728425524ef2 Mon Sep 17 00:00:00 2001
From: "Li, Fei" <fei.li@intel.com>
Date: Thu, 27 Apr 2017 01:47:25 +0000
Subject: cpuidle: check dev before usage in cpuidle_use_deepest_state()
From: Li, Fei <fei.li@intel.com>
commit 41dc750ea67f317c0deedde713d1728425524ef2 upstream.
In case of there is no cpuidle devices registered, dev will be null, and
panic will be triggered like below;
In this patch, add checking of dev before usage, like that done in
cpuidle_idle_call.
Panic without fix:
[ 184.961328] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 184.961328] IP: cpuidle_use_deepest_state+0x30/0x60
...
[ 184.961328] play_idle+0x8d/0x210
[ 184.961328] ? __schedule+0x359/0x8e0
[ 184.961328] ? _raw_spin_unlock_irqrestore+0x28/0x50
[ 184.961328] ? kthread_queue_delayed_work+0x41/0x80
[ 184.961328] clamp_idle_injection_func+0x64/0x1e0
Fixes: bb8313b603eb8 (cpuidle: Allow enforcing deepest idle state selection)
Signed-off-by: Li, Fei <fei.li@intel.com>
Tested-by: Shi, Feng <fengx.shi@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpuidle/cpuidle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -111,7 +111,8 @@ void cpuidle_use_deepest_state(bool enab
preempt_disable();
dev = cpuidle_get_device();
- dev->use_deepest_state = enable;
+ if (dev)
+ dev->use_deepest_state = enable;
preempt_enable();
}
Patches currently in stable-queue which might be from fei.li@intel.com are
queue-4.11/cpuidle-check-dev-before-usage-in-cpuidle_use_deepest_state.patch
^ permalink raw reply
* Patch "arm64: xchg: hazard against entire exchange variable" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: mark.rutland, catalin.marinas, gregkh, will.deacon; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: xchg: hazard against entire exchange variable
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-xchg-hazard-against-entire-exchange-variable.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From fee960bed5e857eb126c4e56dd9ff85938356579 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 3 May 2017 16:09:33 +0100
Subject: arm64: xchg: hazard against entire exchange variable
From: Mark Rutland <mark.rutland@arm.com>
commit fee960bed5e857eb126c4e56dd9ff85938356579 upstream.
The inline assembly in __XCHG_CASE() uses a +Q constraint to hazard
against other accesses to the memory location being exchanged. However,
the pointer passed to the constraint is a u8 pointer, and thus the
hazard only applies to the first byte of the location.
GCC can take advantage of this, assuming that other portions of the
location are unchanged, as demonstrated with the following test case:
union u {
unsigned long l;
unsigned int i[2];
};
unsigned long update_char_hazard(union u *u)
{
unsigned int a, b;
a = u->i[1];
asm ("str %1, %0" : "+Q" (*(char *)&u->l) : "r" (0UL));
b = u->i[1];
return a ^ b;
}
unsigned long update_long_hazard(union u *u)
{
unsigned int a, b;
a = u->i[1];
asm ("str %1, %0" : "+Q" (*(long *)&u->l) : "r" (0UL));
b = u->i[1];
return a ^ b;
}
The linaro 15.08 GCC 5.1.1 toolchain compiles the above as follows when
using -O2 or above:
0000000000000000 <update_char_hazard>:
0: d2800001 mov x1, #0x0 // #0
4: f9000001 str x1, [x0]
8: d2800000 mov x0, #0x0 // #0
c: d65f03c0 ret
0000000000000010 <update_long_hazard>:
10: b9400401 ldr w1, [x0,#4]
14: d2800002 mov x2, #0x0 // #0
18: f9000002 str x2, [x0]
1c: b9400400 ldr w0, [x0,#4]
20: 4a000020 eor w0, w1, w0
24: d65f03c0 ret
This patch fixes the issue by passing an unsigned long pointer into the
+Q constraint, as we do for our cmpxchg code. This may hazard against
more than is necessary, but this is better than missing a necessary
hazard.
Fixes: 305d454aaa29 ("arm64: atomics: implement native {relaxed, acquire, release} atomics")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/cmpxchg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -46,7 +46,7 @@ static inline unsigned long __xchg_case_
" swp" #acq_lse #rel #sz "\t%" #w "3, %" #w "0, %2\n" \
__nops(3) \
" " #nop_lse) \
- : "=&r" (ret), "=&r" (tmp), "+Q" (*(u8 *)ptr) \
+ : "=&r" (ret), "=&r" (tmp), "+Q" (*(unsigned long *)ptr) \
: "r" (x) \
: cl); \
\
Patches currently in stable-queue which might be from mark.rutland@arm.com are
queue-4.11/arm64-armv8_deprecated-ensure-extension-of-addr.patch
queue-4.11/arm64-uaccess-ensure-extension-of-access_ok-addr.patch
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-xchg-hazard-against-entire-exchange-variable.patch
queue-4.11/arm64-ensure-extension-of-smp_store_release-value.patch
^ permalink raw reply
* Patch "genirq: Fix chained interrupt data ordering" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tglx, bp, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
genirq: Fix chained interrupt data ordering
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
genirq-fix-chained-interrupt-data-ordering.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 2c4569ca26986d18243f282dd727da27e9adae4c Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx@linutronix.de>
Date: Thu, 11 May 2017 13:54:11 +0200
Subject: genirq: Fix chained interrupt data ordering
From: Thomas Gleixner <tglx@linutronix.de>
commit 2c4569ca26986d18243f282dd727da27e9adae4c upstream.
irq_set_chained_handler_and_data() sets up the chained interrupt and then
stores the handler data.
That's racy against an immediate interrupt which gets handled before the
store of the handler data happened. The handler will dereference a NULL
pointer and crash.
Cure it by storing handler data before installing the chained handler.
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/irq/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -877,8 +877,8 @@ irq_set_chained_handler_and_data(unsigne
if (!desc)
return;
- __irq_do_set_handler(desc, handle, 1, NULL);
desc->irq_common_data.handler_data = data;
+ __irq_do_set_handler(desc, handle, 1, NULL);
irq_put_desc_busunlock(desc, flags);
}
Patches currently in stable-queue which might be from tglx@linutronix.de are
queue-4.11/stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
queue-4.11/genirq-fix-chained-interrupt-data-ordering.patch
^ permalink raw reply
* Patch "arm64: uaccess: ensure extension of access_ok() addr" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: mark.rutland, catalin.marinas, gregkh, will.deacon; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: uaccess: ensure extension of access_ok() addr
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-uaccess-ensure-extension-of-access_ok-addr.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From a06040d7a791a9177581dcf7293941bd92400856 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 3 May 2017 16:09:35 +0100
Subject: arm64: uaccess: ensure extension of access_ok() addr
From: Mark Rutland <mark.rutland@arm.com>
commit a06040d7a791a9177581dcf7293941bd92400856 upstream.
Our access_ok() simply hands its arguments over to __range_ok(), which
implicitly assummes that the addr parameter is 64 bits wide. This isn't
necessarily true for compat code, which might pass down a 32-bit address
parameter.
In these cases, we don't have a guarantee that the address has been zero
extended to 64 bits, and the upper bits of the register may contain
unknown values, potentially resulting in a suprious failure.
Avoid this by explicitly casting the addr parameter to an unsigned long
(as is done on other architectures), ensuring that the parameter is
widened appropriately.
Fixes: 0aea86a2176c ("arm64: User access library functions")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -95,11 +95,12 @@ static inline void set_fs(mm_segment_t f
*/
#define __range_ok(addr, size) \
({ \
+ unsigned long __addr = (unsigned long __force)(addr); \
unsigned long flag, roksum; \
__chk_user_ptr(addr); \
asm("adds %1, %1, %3; ccmp %1, %4, #2, cc; cset %0, ls" \
: "=&r" (flag), "=&r" (roksum) \
- : "1" (addr), "Ir" (size), \
+ : "1" (__addr), "Ir" (size), \
"r" (current_thread_info()->addr_limit) \
: "cc"); \
flag; \
Patches currently in stable-queue which might be from mark.rutland@arm.com are
queue-4.11/arm64-armv8_deprecated-ensure-extension-of-addr.patch
queue-4.11/arm64-uaccess-ensure-extension-of-access_ok-addr.patch
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-xchg-hazard-against-entire-exchange-variable.patch
queue-4.11/arm64-ensure-extension-of-smp_store_release-value.patch
^ permalink raw reply
* Patch "arm64: traps: fix userspace cache maintenance emulation on a tagged pointer" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: kristina.martsenko, catalin.marinas, gregkh, will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: traps: fix userspace cache maintenance emulation on a tagged pointer
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-traps-fix-userspace-cache-maintenance-emulation-on-a-tagged-pointer.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 81cddd65b5c82758ea5571a25e31ff6f1f89ff02 Mon Sep 17 00:00:00 2001
From: Kristina Martsenko <kristina.martsenko@arm.com>
Date: Wed, 3 May 2017 16:37:45 +0100
Subject: arm64: traps: fix userspace cache maintenance emulation on a tagged pointer
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit 81cddd65b5c82758ea5571a25e31ff6f1f89ff02 upstream.
When we emulate userspace cache maintenance in the kernel, we can
currently send the task a SIGSEGV even though the maintenance was done
on a valid address. This happens if the address has a non-zero address
tag, and happens to not be mapped in.
When we get the address from a user register, we don't currently remove
the address tag before performing cache maintenance on it. If the
maintenance faults, we end up in either __do_page_fault, where find_vma
can't find the VMA if the address has a tag, or in do_translation_fault,
where the tagged address will appear to be above TASK_SIZE. In both
cases, the address is not mapped in, and the task is sent a SIGSEGV.
This patch removes the tag from the address before using it. With this
patch, the fault is handled correctly, the address gets mapped in, and
the cache maintenance succeeds.
As a second bug, if cache maintenance (correctly) fails on an invalid
tagged address, the address gets passed into arm64_notify_segfault,
where find_vma fails to find the VMA due to the tag, and the wrong
si_code may be sent as part of the siginfo_t of the segfault. With this
patch, the correct si_code is sent.
Fixes: 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -443,7 +443,7 @@ int cpu_enable_cache_maint_trap(void *__
}
#define __user_cache_maint(insn, address, res) \
- if (untagged_addr(address) >= user_addr_max()) { \
+ if (address >= user_addr_max()) { \
res = -EFAULT; \
} else { \
uaccess_ttbr0_enable(); \
@@ -469,7 +469,7 @@ static void user_cache_maint_handler(uns
int crm = (esr & ESR_ELx_SYS64_ISS_CRM_MASK) >> ESR_ELx_SYS64_ISS_CRM_SHIFT;
int ret = 0;
- address = pt_regs_read_reg(regs, rt);
+ address = untagged_addr(pt_regs_read_reg(regs, rt));
switch (crm) {
case ESR_ELx_SYS64_ISS_CRM_DC_CVAU: /* DC CVAU, gets promoted */
Patches currently in stable-queue which might be from kristina.martsenko@arm.com are
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-entry-improve-data-abort-handling-of-tagged-pointers.patch
queue-4.11/arm64-documentation-document-tagged-pointer-stack-constraints.patch
queue-4.11/arm64-traps-fix-userspace-cache-maintenance-emulation-on-a-tagged-pointer.patch
^ permalink raw reply
* Patch "arm64: hw_breakpoint: fix watchpoint matching for tagged pointers" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: kristina.martsenko, catalin.marinas, gregkh, mark.rutland,
will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: hw_breakpoint: fix watchpoint matching for tagged pointers
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 7dcd9dd8cebe9fa626af7e2358d03a37041a70fb Mon Sep 17 00:00:00 2001
From: Kristina Martsenko <kristina.martsenko@arm.com>
Date: Wed, 3 May 2017 16:37:46 +0100
Subject: arm64: hw_breakpoint: fix watchpoint matching for tagged pointers
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit 7dcd9dd8cebe9fa626af7e2358d03a37041a70fb upstream.
When we take a watchpoint exception, the address that triggered the
watchpoint is found in FAR_EL1. We compare it to the address of each
configured watchpoint to see which one was hit.
The configured watchpoint addresses are untagged, while the address in
FAR_EL1 will have an address tag if the data access was done using a
tagged address. The tag needs to be removed to compare the address to
the watchpoints.
Currently we don't remove it, and as a result can report the wrong
watchpoint as being hit (specifically, always either the highest TTBR0
watchpoint or lowest TTBR1 watchpoint). This patch removes the tag.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/uaccess.h | 6 +++---
arch/arm64/kernel/hw_breakpoint.c | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -107,9 +107,9 @@ static inline void set_fs(mm_segment_t f
})
/*
- * When dealing with data aborts or instruction traps we may end up with
- * a tagged userland pointer. Clear the tag to get a sane pointer to pass
- * on to access_ok(), for instance.
+ * When dealing with data aborts, watchpoints, or instruction traps we may end
+ * up with a tagged userland pointer. Clear the tag to get a sane pointer to
+ * pass on to access_ok(), for instance.
*/
#define untagged_addr(addr) sign_extend64(addr, 55)
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -36,6 +36,7 @@
#include <asm/traps.h>
#include <asm/cputype.h>
#include <asm/system_misc.h>
+#include <asm/uaccess.h>
/* Breakpoint currently in use for each BRP. */
static DEFINE_PER_CPU(struct perf_event *, bp_on_reg[ARM_MAX_BRP]);
@@ -721,6 +722,8 @@ static u64 get_distance_from_watchpoint(
u64 wp_low, wp_high;
u32 lens, lene;
+ addr = untagged_addr(addr);
+
lens = __ffs(ctrl->len);
lene = __fls(ctrl->len);
Patches currently in stable-queue which might be from kristina.martsenko@arm.com are
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-entry-improve-data-abort-handling-of-tagged-pointers.patch
queue-4.11/arm64-documentation-document-tagged-pointer-stack-constraints.patch
queue-4.11/arm64-traps-fix-userspace-cache-maintenance-emulation-on-a-tagged-pointer.patch
^ permalink raw reply
* Patch "arm64: KVM: Do not use stack-protector to compile EL2 code" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: marc.zyngier, cdall, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: KVM: Do not use stack-protector to compile EL2 code
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-kvm-do-not-use-stack-protector-to-compile-el2-code.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From cde13b5dad60471886a3bccb4f4134c647c4a9dc Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue, 2 May 2017 14:30:37 +0100
Subject: arm64: KVM: Do not use stack-protector to compile EL2 code
From: Marc Zyngier <marc.zyngier@arm.com>
commit cde13b5dad60471886a3bccb4f4134c647c4a9dc upstream.
We like living dangerously. Nothing explicitely forbids stack-protector
to be used in the EL2 code, while distributions routinely compile their
kernel with it. We're just lucky that no code actually triggers the
instrumentation.
Let's not try our luck for much longer, and disable stack-protector
for code living at EL2.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kvm/hyp/Makefile | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@ -2,6 +2,8 @@
# Makefile for Kernel-based Virtual Machine module, HYP part
#
+ccflags-y += -fno-stack-protector
+
KVM=../../../../virt/kvm
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
Patches currently in stable-queue which might be from marc.zyngier@arm.com are
queue-4.11/arm64-kvm-do-not-use-stack-protector-to-compile-el2-code.patch
queue-4.11/arm-kvm-do-not-use-stack-protector-to-compile-hyp-code.patch
queue-4.11/kvm-arm-arm64-vgic-v3-do-not-use-active-pending-state-for-a-hw-interrupt.patch
queue-4.11/kvm-arm-arm64-vgic-v2-do-not-use-active-pending-state-for-a-hw-interrupt.patch
^ permalink raw reply
* Patch "arm64: entry: improve data abort handling of tagged pointers" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: kristina.martsenko, Dave.Martin, catalin.marinas, gregkh,
will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: entry: improve data abort handling of tagged pointers
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-entry-improve-data-abort-handling-of-tagged-pointers.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 276e93279a630657fff4b086ba14c95955912dfa Mon Sep 17 00:00:00 2001
From: Kristina Martsenko <kristina.martsenko@arm.com>
Date: Wed, 3 May 2017 16:37:47 +0100
Subject: arm64: entry: improve data abort handling of tagged pointers
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit 276e93279a630657fff4b086ba14c95955912dfa upstream.
When handling a data abort from EL0, we currently zero the top byte of
the faulting address, as we assume the address is a TTBR0 address, which
may contain a non-zero address tag. However, the address may be a TTBR1
address, in which case we should not zero the top byte. This patch fixes
that. The effect is that the full TTBR1 address is passed to the task's
signal handler (or printed out in the kernel log).
When handling a data abort from EL1, we leave the faulting address
intact, as we assume it's either a TTBR1 address or a TTBR0 address with
tag 0x00. This is true as far as I'm aware, we don't seem to access a
tagged TTBR0 address anywhere in the kernel. Regardless, it's easy to
forget about address tags, and code added in the future may not always
remember to remove tags from addresses before accessing them. So add tag
handling to the EL1 data abort handler as well. This also makes it
consistent with the EL0 data abort handler.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/asm-uaccess.h | 9 +++++++++
arch/arm64/kernel/entry.S | 5 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/arch/arm64/include/asm/asm-uaccess.h
+++ b/arch/arm64/include/asm/asm-uaccess.h
@@ -62,4 +62,13 @@ alternative_if ARM64_ALT_PAN_NOT_UAO
alternative_else_nop_endif
.endm
+/*
+ * Remove the address tag from a virtual address, if present.
+ */
+ .macro clear_address_tag, dst, addr
+ tst \addr, #(1 << 55)
+ bic \dst, \addr, #(0xff << 56)
+ csel \dst, \dst, \addr, eq
+ .endm
+
#endif
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -428,12 +428,13 @@ el1_da:
/*
* Data abort handling
*/
- mrs x0, far_el1
+ mrs x3, far_el1
enable_dbg
// re-enable interrupts if they were enabled in the aborted context
tbnz x23, #7, 1f // PSR_I_BIT
enable_irq
1:
+ clear_address_tag x0, x3
mov x2, sp // struct pt_regs
bl do_mem_abort
@@ -594,7 +595,7 @@ el0_da:
// enable interrupts before calling the main handler
enable_dbg_and_irq
ct_user_exit
- bic x0, x26, #(0xff << 56)
+ clear_address_tag x0, x26
mov x1, x25
mov x2, sp
bl do_mem_abort
Patches currently in stable-queue which might be from kristina.martsenko@arm.com are
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-entry-improve-data-abort-handling-of-tagged-pointers.patch
queue-4.11/arm64-documentation-document-tagged-pointer-stack-constraints.patch
queue-4.11/arm64-traps-fix-userspace-cache-maintenance-emulation-on-a-tagged-pointer.patch
^ permalink raw reply
* Patch "arm64: ensure extension of smp_store_release value" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: mark.rutland, catalin.marinas, gregkh, mka, will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: ensure extension of smp_store_release value
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-ensure-extension-of-smp_store_release-value.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 994870bead4ab19087a79492400a5478e2906196 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 3 May 2017 16:09:34 +0100
Subject: arm64: ensure extension of smp_store_release value
From: Mark Rutland <mark.rutland@arm.com>
commit 994870bead4ab19087a79492400a5478e2906196 upstream.
When an inline assembly operand's type is narrower than the register it
is allocated to, the least significant bits of the register (up to the
operand type's width) are valid, and any other bits are permitted to
contain any arbitrary value. This aligns with the AAPCS64 parameter
passing rules.
Our __smp_store_release() implementation does not account for this, and
implicitly assumes that operands have been zero-extended to the width of
the type being stored to. Thus, we may store unknown values to memory
when the value type is narrower than the pointer type (e.g. when storing
a char to a long).
This patch fixes the issue by casting the value operand to the same
width as the pointer operand in all cases, which ensures that the value
is zero-extended as we expect. We use the same union trickery as
__smp_load_acquire and {READ,WRITE}_ONCE() to avoid GCC complaining that
pointers are potentially cast to narrower width integers in unreachable
paths.
A whitespace issue at the top of __smp_store_release() is also
corrected.
No changes are necessary for __smp_load_acquire(). Load instructions
implicitly clear any upper bits of the register, and the compiler will
only consider the least significant bits of the register as valid
regardless.
Fixes: 47933ad41a86 ("arch: Introduce smp_load_acquire(), smp_store_release()")
Fixes: 878a84d5a8a1 ("arm64: add missing data types in smp_load_acquire/smp_store_release")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/barrier.h | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -42,25 +42,35 @@
#define __smp_rmb() dmb(ishld)
#define __smp_wmb() dmb(ishst)
-#define __smp_store_release(p, v) \
+#define __smp_store_release(p, v) \
do { \
+ union { typeof(*p) __val; char __c[1]; } __u = \
+ { .__val = (__force typeof(*p)) (v) }; \
compiletime_assert_atomic_type(*p); \
switch (sizeof(*p)) { \
case 1: \
asm volatile ("stlrb %w1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u8 *)__u.__c) \
+ : "memory"); \
break; \
case 2: \
asm volatile ("stlrh %w1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u16 *)__u.__c) \
+ : "memory"); \
break; \
case 4: \
asm volatile ("stlr %w1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u32 *)__u.__c) \
+ : "memory"); \
break; \
case 8: \
asm volatile ("stlr %1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u64 *)__u.__c) \
+ : "memory"); \
break; \
} \
} while (0)
Patches currently in stable-queue which might be from mark.rutland@arm.com are
queue-4.11/arm64-armv8_deprecated-ensure-extension-of-addr.patch
queue-4.11/arm64-uaccess-ensure-extension-of-access_ok-addr.patch
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-xchg-hazard-against-entire-exchange-variable.patch
queue-4.11/arm64-ensure-extension-of-smp_store_release-value.patch
^ permalink raw reply
* Patch "arm64: dts: hi6220: Reset the mmc hosts" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: daniel.lezcano, gregkh, xuwei5; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: dts: hi6220: Reset the mmc hosts
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-dts-hi6220-reset-the-mmc-hosts.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 0fbdf9953b41c28845fe8d05007ff09634ee3000 Mon Sep 17 00:00:00 2001
From: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Thu, 16 Mar 2017 15:03:24 +0100
Subject: arm64: dts: hi6220: Reset the mmc hosts
From: Daniel Lezcano <daniel.lezcano@linaro.org>
commit 0fbdf9953b41c28845fe8d05007ff09634ee3000 upstream.
The MMC hosts could be left in an unconsistent or uninitialized state from
the firmware. Instead of assuming, the firmware did the right things, let's
reset the host controllers.
This change fixes a bug when the mmc2/sdio is initialized leading to a hung
task:
[ 242.704294] INFO: task kworker/7:1:675 blocked for more than 120 seconds.
[ 242.711129] Not tainted 4.9.0-rc8-00017-gcf0251f #3
[ 242.716571] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 242.724435] kworker/7:1 D 0 675 2 0x00000000
[ 242.729973] Workqueue: events_freezable mmc_rescan
[ 242.734796] Call trace:
[ 242.737269] [<ffff00000808611c>] __switch_to+0xa8/0xb4
[ 242.742437] [<ffff000008d07c04>] __schedule+0x1c0/0x67c
[ 242.747689] [<ffff000008d08254>] schedule+0x40/0xa0
[ 242.752594] [<ffff000008d0b284>] schedule_timeout+0x1c4/0x35c
[ 242.758366] [<ffff000008d08e38>] wait_for_common+0xd0/0x15c
[ 242.763964] [<ffff000008d09008>] wait_for_completion+0x28/0x34
[ 242.769825] [<ffff000008a1a9f4>] mmc_wait_for_req_done+0x40/0x124
[ 242.775949] [<ffff000008a1ab98>] mmc_wait_for_req+0xc0/0xf8
[ 242.781549] [<ffff000008a1ac3c>] mmc_wait_for_cmd+0x6c/0x84
[ 242.787149] [<ffff000008a26610>] mmc_io_rw_direct_host+0x9c/0x114
[ 242.793270] [<ffff000008a26aa0>] sdio_reset+0x34/0x7c
[ 242.798347] [<ffff000008a1d46c>] mmc_rescan+0x2fc/0x360
[ ... ]
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -774,6 +774,7 @@
clocks = <&sys_ctrl 2>, <&sys_ctrl 1>;
clock-names = "ciu", "biu";
resets = <&sys_ctrl PERIPH_RSTDIS0_MMC0>;
+ reset-names = "reset";
bus-width = <0x8>;
vmmc-supply = <&ldo19>;
pinctrl-names = "default";
@@ -797,6 +798,7 @@
clocks = <&sys_ctrl 4>, <&sys_ctrl 3>;
clock-names = "ciu", "biu";
resets = <&sys_ctrl PERIPH_RSTDIS0_MMC1>;
+ reset-names = "reset";
vqmmc-supply = <&ldo7>;
vmmc-supply = <&ldo10>;
bus-width = <0x4>;
@@ -815,6 +817,7 @@
clocks = <&sys_ctrl HI6220_MMC2_CIUCLK>, <&sys_ctrl HI6220_MMC2_CLK>;
clock-names = "ciu", "biu";
resets = <&sys_ctrl PERIPH_RSTDIS0_MMC2>;
+ reset-names = "reset";
bus-width = <0x4>;
broken-cd;
pinctrl-names = "default", "idle";
Patches currently in stable-queue which might be from daniel.lezcano@linaro.org are
queue-4.11/arm64-dts-hi6220-reset-the-mmc-hosts.patch
^ permalink raw reply
* Patch "arm64: documentation: document tagged pointer stack constraints" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: kristina.martsenko, Dave.Martin, catalin.marinas, gregkh,
will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: documentation: document tagged pointer stack constraints
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-documentation-document-tagged-pointer-stack-constraints.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From f0e421b1bf7af97f026e1bb8bfe4c5a7a8c08f42 Mon Sep 17 00:00:00 2001
From: Kristina Martsenko <kristina.martsenko@arm.com>
Date: Wed, 3 May 2017 16:37:48 +0100
Subject: arm64: documentation: document tagged pointer stack constraints
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit f0e421b1bf7af97f026e1bb8bfe4c5a7a8c08f42 upstream.
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/arm64/tagged-pointers.txt | 66 +++++++++++++++++++++++---------
1 file changed, 49 insertions(+), 17 deletions(-)
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -11,24 +11,56 @@ in AArch64 Linux.
The kernel configures the translation tables so that translations made
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
the virtual address ignored by the translation hardware. This frees up
-this byte for application use, with the following caveats:
+this byte for application use.
- (1) The kernel requires that all user addresses passed to EL1
- are tagged with tag 0x00. This means that any syscall
- parameters containing user virtual addresses *must* have
- their top byte cleared before trapping to the kernel.
-
- (2) Non-zero tags are not preserved when delivering signals.
- This means that signal handlers in applications making use
- of tags cannot rely on the tag information for user virtual
- addresses being maintained for fields inside siginfo_t.
- One exception to this rule is for signals raised in response
- to watchpoint debug exceptions, where the tag information
- will be preserved.
-
- (3) Special care should be taken when using tagged pointers,
- since it is likely that C compilers will not hazard two
- virtual addresses differing only in the upper byte.
+
+Passing tagged addresses to the kernel
+--------------------------------------
+
+All interpretation of userspace memory addresses by the kernel assumes
+an address tag of 0x00.
+
+This includes, but is not limited to, addresses found in:
+
+ - pointer arguments to system calls, including pointers in structures
+ passed to system calls,
+
+ - the stack pointer (sp), e.g. when interpreting it to deliver a
+ signal,
+
+ - the frame pointer (x29) and frame records, e.g. when interpreting
+ them to generate a backtrace or call graph.
+
+Using non-zero address tags in any of these locations may result in an
+error code being returned, a (fatal) signal being raised, or other modes
+of failure.
+
+For these reasons, passing non-zero address tags to the kernel via
+system calls is forbidden, and using a non-zero address tag for sp is
+strongly discouraged.
+
+Programs maintaining a frame pointer and frame records that use non-zero
+address tags may suffer impaired or inaccurate debug and profiling
+visibility.
+
+
+Preserving tags
+---------------
+
+Non-zero tags are not preserved when delivering signals. This means that
+signal handlers in applications making use of tags cannot rely on the
+tag information for user virtual addresses being maintained for fields
+inside siginfo_t. One exception to this rule is for signals raised in
+response to watchpoint debug exceptions, where the tag information will
+be preserved.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
+
+
+Other considerations
+--------------------
+
+Special care should be taken when using tagged pointers, since it is
+likely that C compilers will not hazard two virtual addresses differing
+only in the upper byte.
Patches currently in stable-queue which might be from kristina.martsenko@arm.com are
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-entry-improve-data-abort-handling-of-tagged-pointers.patch
queue-4.11/arm64-documentation-document-tagged-pointer-stack-constraints.patch
queue-4.11/arm64-traps-fix-userspace-cache-maintenance-emulation-on-a-tagged-pointer.patch
^ permalink raw reply
* Patch "arm64: armv8_deprecated: ensure extension of addr" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: mark.rutland, catalin.marinas, gregkh, will.deacon; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: armv8_deprecated: ensure extension of addr
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-armv8_deprecated-ensure-extension-of-addr.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 55de49f9aa17b0b2b144dd2af587177b9aadf429 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 3 May 2017 16:09:36 +0100
Subject: arm64: armv8_deprecated: ensure extension of addr
From: Mark Rutland <mark.rutland@arm.com>
commit 55de49f9aa17b0b2b144dd2af587177b9aadf429 upstream.
Our compat swp emulation holds the compat user address in an unsigned
int, which it passes to __user_swpX_asm(). When a 32-bit value is passed
in a register, the upper 32 bits of the register are unknown, and we
must extend the value to 64 bits before we can use it as a base address.
This patch casts the address to unsigned long to ensure it has been
suitably extended, avoiding the potential issue, and silencing a related
warning from clang.
Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/armv8_deprecated.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -306,7 +306,8 @@ do { \
_ASM_EXTABLE(0b, 4b) \
_ASM_EXTABLE(1b, 4b) \
: "=&r" (res), "+r" (data), "=&r" (temp), "=&r" (temp2) \
- : "r" (addr), "i" (-EAGAIN), "i" (-EFAULT), \
+ : "r" ((unsigned long)addr), "i" (-EAGAIN), \
+ "i" (-EFAULT), \
"i" (__SWP_LL_SC_LOOPS) \
: "memory"); \
uaccess_disable(); \
Patches currently in stable-queue which might be from mark.rutland@arm.com are
queue-4.11/arm64-armv8_deprecated-ensure-extension-of-addr.patch
queue-4.11/arm64-uaccess-ensure-extension-of-access_ok-addr.patch
queue-4.11/arm64-hw_breakpoint-fix-watchpoint-matching-for-tagged-pointers.patch
queue-4.11/arm64-xchg-hazard-against-entire-exchange-variable.patch
queue-4.11/arm64-ensure-extension-of-smp_store_release-value.patch
^ permalink raw reply
* Patch "ARM: dts: imx6sx-sdb: Remove OPP override" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: leonard.crestez, gregkh, shawnguo; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: imx6sx-sdb: Remove OPP override
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-imx6sx-sdb-remove-opp-override.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d8581c7c8be172dac156a19d261f988a72ce596f Mon Sep 17 00:00:00 2001
From: Leonard Crestez <leonard.crestez@nxp.com>
Date: Fri, 5 May 2017 14:00:17 +0300
Subject: ARM: dts: imx6sx-sdb: Remove OPP override
From: Leonard Crestez <leonard.crestez@nxp.com>
commit d8581c7c8be172dac156a19d261f988a72ce596f upstream.
The board file for imx6sx-sdb overrides cpufreq operating points to use
higher voltages. This is done because the board has a shared rail for
VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage
needs to be a value suitable for both ARM and SOC.
This only applies to LDO bypass mode, a feature not present in upstream.
When LDOs are enabled the effect is to use higher voltages than necessary
for no good reason.
Setting these higher voltages can make some boards fail to boot with ugly
semi-random crashes reminiscent of memory corruption. These failures only
happen on board rev. C, rev. B is reported to still work.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Fixes: 54183bd7f766 ("ARM: imx6sx-sdb: add revb board and make it default")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/imx6sx-sdb.dts | 17 -----------------
1 file changed, 17 deletions(-)
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -12,23 +12,6 @@
model = "Freescale i.MX6 SoloX SDB RevB Board";
};
-&cpu0 {
- operating-points = <
- /* kHz uV */
- 996000 1250000
- 792000 1175000
- 396000 1175000
- 198000 1175000
- >;
- fsl,soc-operating-points = <
- /* ARM kHz SOC uV */
- 996000 1250000
- 792000 1175000
- 396000 1175000
- 198000 1175000
- >;
-};
-
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
Patches currently in stable-queue which might be from leonard.crestez@nxp.com are
queue-4.11/arm-dts-imx6sx-sdb-remove-opp-override.patch
^ permalink raw reply
* Patch "arm: KVM: Do not use stack-protector to compile HYP code" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: marc.zyngier, cdall, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm: KVM: Do not use stack-protector to compile HYP code
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-kvm-do-not-use-stack-protector-to-compile-hyp-code.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 501ad27c67ed0b90df465f23d33e9aed64058a47 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue, 2 May 2017 14:30:38 +0100
Subject: arm: KVM: Do not use stack-protector to compile HYP code
From: Marc Zyngier <marc.zyngier@arm.com>
commit 501ad27c67ed0b90df465f23d33e9aed64058a47 upstream.
We like living dangerously. Nothing explicitely forbids stack-protector
to be used in the HYP code, while distributions routinely compile their
kernel with it. We're just lucky that no code actually triggers the
instrumentation.
Let's not try our luck for much longer, and disable stack-protector
for code living at HYP.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/kvm/hyp/Makefile | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -2,6 +2,8 @@
# Makefile for Kernel-based Virtual Machine module, HYP part
#
+ccflags-y += -fno-stack-protector
+
KVM=../../../../virt/kvm
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
Patches currently in stable-queue which might be from marc.zyngier@arm.com are
queue-4.11/arm64-kvm-do-not-use-stack-protector-to-compile-el2-code.patch
queue-4.11/arm-kvm-do-not-use-stack-protector-to-compile-hyp-code.patch
queue-4.11/kvm-arm-arm64-vgic-v3-do-not-use-active-pending-state-for-a-hw-interrupt.patch
queue-4.11/kvm-arm-arm64-vgic-v2-do-not-use-active-pending-state-for-a-hw-interrupt.patch
^ permalink raw reply
* Patch "ARM: dts: at91: sama5d3_xplained: fix ADC vref" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: ludovic.desroches, alexandre.belloni, gregkh, nicolas.ferre
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: at91: sama5d3_xplained: fix ADC vref
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-at91-sama5d3_xplained-fix-adc-vref.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 9cdd31e5913c1f86dce7e201b086155b3f24896b Mon Sep 17 00:00:00 2001
From: Ludovic Desroches <ludovic.desroches@microchip.com>
Date: Mon, 10 Apr 2017 10:25:16 +0200
Subject: ARM: dts: at91: sama5d3_xplained: fix ADC vref
From: Ludovic Desroches <ludovic.desroches@microchip.com>
commit 9cdd31e5913c1f86dce7e201b086155b3f24896b upstream.
The voltage reference for the ADC is not 3V but 3.3V since it is connected to
VDDANA.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -162,6 +162,7 @@
};
adc0: adc@f8018000 {
+ atmel,adc-vref = <3300>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
&pinctrl_adc0_ad0
Patches currently in stable-queue which might be from ludovic.desroches@microchip.com are
queue-4.11/arm-dts-at91-sama5d3_xplained-fix-adc-vref.patch
queue-4.11/arm-dts-at91-sama5d3_xplained-not-all-adc-channels-are-available.patch
^ permalink raw reply
* Patch "ARM: dts: at91: sama5d3_xplained: not all ADC channels are available" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: ludovic.desroches, alexandre.belloni, gregkh, nicolas.ferre
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-at91-sama5d3_xplained-not-all-adc-channels-are-available.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d3df1ec06353e51fc44563d2e7e18d42811af290 Mon Sep 17 00:00:00 2001
From: Ludovic Desroches <ludovic.desroches@microchip.com>
Date: Mon, 10 Apr 2017 10:25:17 +0200
Subject: ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
From: Ludovic Desroches <ludovic.desroches@microchip.com>
commit d3df1ec06353e51fc44563d2e7e18d42811af290 upstream.
Remove ADC channels that are not available by default on the sama5d3_xplained
board (resistor not populated) in order to not create confusion.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -163,9 +163,9 @@
adc0: adc@f8018000 {
atmel,adc-vref = <3300>;
+ atmel,adc-channels-used = <0xfe>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
- &pinctrl_adc0_ad0
&pinctrl_adc0_ad1
&pinctrl_adc0_ad2
&pinctrl_adc0_ad3
@@ -173,8 +173,6 @@
&pinctrl_adc0_ad5
&pinctrl_adc0_ad6
&pinctrl_adc0_ad7
- &pinctrl_adc0_ad8
- &pinctrl_adc0_ad9
>;
status = "okay";
};
Patches currently in stable-queue which might be from ludovic.desroches@microchip.com are
queue-4.11/arm-dts-at91-sama5d3_xplained-fix-adc-vref.patch
queue-4.11/arm-dts-at91-sama5d3_xplained-not-all-adc-channels-are-available.patch
^ permalink raw reply
* Patch "ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tixy, afzal.mohd.ma, ard.biesheuvel, gregkh, rmk+kernel
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-8667-3-fix-memory-attribute-inconsistencies-when-using-fixmap.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From b089c31c519c3906c14801b6ec483e18a5152a50 Mon Sep 17 00:00:00 2001
From: Jon Medhurst <tixy@linaro.org>
Date: Mon, 10 Apr 2017 11:13:59 +0100
Subject: ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap
From: Jon Medhurst <tixy@linaro.org>
commit b089c31c519c3906c14801b6ec483e18a5152a50 upstream.
To cope with the variety in ARM architectures and configurations, the
pagetable attributes for kernel memory are generated at runtime to match
the system the kernel finds itself on. This calculated value is stored
in pgprot_kernel.
However, when early fixmap support was added for ARM (commit
a5f4c561b3b1) the attributes used for mappings were hard coded because
pgprot_kernel is not set up early enough. Unfortunately, when fixmap is
used after early boot this means the memory being mapped can have
different attributes to existing mappings, potentially leading to
unpredictable behaviour. A specific problem also exists due to the hard
coded values not include the 'shareable' attribute which means on
systems where this matters (e.g. those with multiple CPU clusters) the
cache contents for a memory location can become inconsistent between
CPUs.
To resolve these issues we change fixmap to use the same memory
attributes (from pgprot_kernel) that the rest of the kernel uses. To
enable this we need to refactor the initialisation code so
build_mem_type_table() is called early enough. Note, that relies on early
param parsing for memory type overrides passed via the kernel command
line, so we need to make sure this call is still after
parse_early_params().
[ardb: keep early_fixmap_init() before param parsing, for earlycon]
Fixes: a5f4c561b3b1 ("ARM: 8415/1: early fixmap support for earlycon")
Tested-by: afzal mohammed <afzal.mohd.ma@gmail.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/fixmap.h | 2 +-
arch/arm/kernel/setup.c | 4 ++--
arch/arm/mm/mmu.c | 16 +++++++++++++---
3 files changed, 16 insertions(+), 6 deletions(-)
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -41,7 +41,7 @@ static const enum fixed_addresses __end_
#define FIXMAP_PAGE_COMMON (L_PTE_YOUNG | L_PTE_PRESENT | L_PTE_XN | L_PTE_DIRTY)
-#define FIXMAP_PAGE_NORMAL (FIXMAP_PAGE_COMMON | L_PTE_MT_WRITEBACK)
+#define FIXMAP_PAGE_NORMAL (pgprot_kernel | L_PTE_XN)
#define FIXMAP_PAGE_RO (FIXMAP_PAGE_NORMAL | L_PTE_RDONLY)
/* Used by set_fixmap_(io|nocache), both meant for mapping a device */
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -80,7 +80,7 @@ __setup("fpe=", fpe_setup);
extern void init_default_cache_policy(unsigned long);
extern void paging_init(const struct machine_desc *desc);
-extern void early_paging_init(const struct machine_desc *);
+extern void early_mm_init(const struct machine_desc *);
extern void adjust_lowmem_bounds(void);
extern enum reboot_mode reboot_mode;
extern void setup_dma_zone(const struct machine_desc *desc);
@@ -1088,7 +1088,7 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
#ifdef CONFIG_MMU
- early_paging_init(mdesc);
+ early_mm_init(mdesc);
#endif
setup_dma_zone(mdesc);
xen_early_init();
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -414,6 +414,11 @@ void __set_fixmap(enum fixed_addresses i
FIXADDR_END);
BUG_ON(idx >= __end_of_fixed_addresses);
+ /* we only support device mappings until pgprot_kernel has been set */
+ if (WARN_ON(pgprot_val(prot) != pgprot_val(FIXMAP_PAGE_IO) &&
+ pgprot_val(pgprot_kernel) == 0))
+ return;
+
if (pgprot_val(prot))
set_pte_at(NULL, vaddr, pte,
pfn_pte(phys >> PAGE_SHIFT, prot));
@@ -1492,7 +1497,7 @@ pgtables_remap lpae_pgtables_remap_asm;
* early_paging_init() recreates boot time page table setup, allowing machines
* to switch over to a high (>4G) address space on LPAE systems
*/
-void __init early_paging_init(const struct machine_desc *mdesc)
+static void __init early_paging_init(const struct machine_desc *mdesc)
{
pgtables_remap *lpae_pgtables_remap;
unsigned long pa_pgd;
@@ -1560,7 +1565,7 @@ void __init early_paging_init(const stru
#else
-void __init early_paging_init(const struct machine_desc *mdesc)
+static void __init early_paging_init(const struct machine_desc *mdesc)
{
long long offset;
@@ -1616,7 +1621,6 @@ void __init paging_init(const struct mac
{
void *zero_page;
- build_mem_type_table();
prepare_page_table();
map_lowmem();
memblock_set_current_limit(arm_lowmem_limit);
@@ -1636,3 +1640,9 @@ void __init paging_init(const struct mac
empty_zero_page = virt_to_page(zero_page);
__flush_dcache_page(NULL, empty_zero_page);
}
+
+void __init early_mm_init(const struct machine_desc *mdesc)
+{
+ build_mem_type_table();
+ early_paging_init(mdesc);
+}
Patches currently in stable-queue which might be from tixy@linaro.org are
queue-4.11/arm-8667-3-fix-memory-attribute-inconsistencies-when-using-fixmap.patch
^ permalink raw reply
* Patch "ARM: 8670/1: V7M: Do not corrupt vector table around v7m_invalidate_l1 call" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: vladimir.murzin, gregkh, rmk+kernel; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: 8670/1: V7M: Do not corrupt vector table around v7m_invalidate_l1 call
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-8670-1-v7m-do-not-corrupt-vector-table-around-v7m_invalidate_l1-call.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 6d80594936914e798b1b54b3bfe4bd68d8418966 Mon Sep 17 00:00:00 2001
From: Vladimir Murzin <vladimir.murzin@arm.com>
Date: Mon, 24 Apr 2017 10:40:48 +0100
Subject: ARM: 8670/1: V7M: Do not corrupt vector table around v7m_invalidate_l1 call
From: Vladimir Murzin <vladimir.murzin@arm.com>
commit 6d80594936914e798b1b54b3bfe4bd68d8418966 upstream.
We save/restore registers around v7m_invalidate_l1 to address pointed
by r12, which is vector table, so the first eight entries are
overwritten with a garbage. We already have stack setup at that stage,
so use it to save/restore register.
Fixes: 6a8146f420be ("ARM: 8609/1: V7M: Add support for the Cortex-M7 processor")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mm/proc-v7m.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/mm/proc-v7m.S
+++ b/arch/arm/mm/proc-v7m.S
@@ -147,10 +147,10 @@ __v7m_setup_cont:
@ Configure caches (if implemented)
teq r8, #0
- stmneia r12, {r0-r6, lr} @ v7m_invalidate_l1 touches r0-r6
+ stmneia sp, {r0-r6, lr} @ v7m_invalidate_l1 touches r0-r6
blne v7m_invalidate_l1
teq r8, #0 @ re-evalutae condition
- ldmneia r12, {r0-r6, lr}
+ ldmneia sp, {r0-r6, lr}
@ Configure the System Control Register to ensure 8-byte stack alignment
@ Note the STKALIGN bit is either RW or RAO.
Patches currently in stable-queue which might be from vladimir.murzin@arm.com are
queue-4.11/arm-8670-1-v7m-do-not-corrupt-vector-table-around-v7m_invalidate_l1-call.patch
^ permalink raw reply
* Patch "ARM: 8662/1: module: split core and init PLT sections" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: ard.biesheuvel, angus, gregkh, rmk+kernel; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: 8662/1: module: split core and init PLT sections
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-8662-1-module-split-core-and-init-plt-sections.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From b7ede5a1f5905ac394cc8e61712a13e3c5cb7b8f Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Wed, 22 Feb 2017 19:40:12 +0100
Subject: ARM: 8662/1: module: split core and init PLT sections
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
commit b7ede5a1f5905ac394cc8e61712a13e3c5cb7b8f upstream.
Since commit 35fa91eed817 ("ARM: kernel: merge core and init PLTs"),
the ARM module PLT code allocates all PLT entries in a single core
section, since the overhead of having a separate init PLT section is
not justified by the small number of PLT entries usually required for
init code.
However, the core and init module regions are allocated independently,
and there is a corner case where the core region may be allocated from
the VMALLOC region if the dedicated module region is exhausted, but the
init region, being much smaller, can still be allocated from the module
region. This puts the PLT entries out of reach of the relocated branch
instructions, defeating the whole purpose of PLTs.
So split the core and init PLT regions, and name the latter ".init.plt"
so it gets allocated along with (and sufficiently close to) the .init
sections that it serves. Also, given that init PLT entries may need to
be emitted for branches that target the core module, modify the logic
that disregards defined symbols to only disregard symbols that are
defined in the same section.
Fixes: 35fa91eed817 ("ARM: kernel: merge core and init PLTs")
Reported-by: Angus Clark <angus@angusclark.org>
Tested-by: Angus Clark <angus@angusclark.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/module.h | 9 +++-
arch/arm/kernel/module-plts.c | 85 +++++++++++++++++++++++++++++-------------
arch/arm/kernel/module.lds | 1
3 files changed, 67 insertions(+), 28 deletions(-)
--- a/arch/arm/include/asm/module.h
+++ b/arch/arm/include/asm/module.h
@@ -18,13 +18,18 @@ enum {
};
#endif
+struct mod_plt_sec {
+ struct elf32_shdr *plt;
+ int plt_count;
+};
+
struct mod_arch_specific {
#ifdef CONFIG_ARM_UNWIND
struct unwind_table *unwind[ARM_SEC_MAX];
#endif
#ifdef CONFIG_ARM_MODULE_PLTS
- struct elf32_shdr *plt;
- int plt_count;
+ struct mod_plt_sec core;
+ struct mod_plt_sec init;
#endif
};
--- a/arch/arm/kernel/module-plts.c
+++ b/arch/arm/kernel/module-plts.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ * Copyright (C) 2014-2017 Linaro Ltd. <ard.biesheuvel@linaro.org>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -31,9 +31,17 @@ struct plt_entries {
u32 lit[PLT_ENT_COUNT];
};
+static bool in_init(const struct module *mod, unsigned long loc)
+{
+ return loc - (u32)mod->init_layout.base < mod->init_layout.size;
+}
+
u32 get_module_plt(struct module *mod, unsigned long loc, Elf32_Addr val)
{
- struct plt_entries *plt = (struct plt_entries *)mod->arch.plt->sh_addr;
+ struct mod_plt_sec *pltsec = !in_init(mod, loc) ? &mod->arch.core :
+ &mod->arch.init;
+
+ struct plt_entries *plt = (struct plt_entries *)pltsec->plt->sh_addr;
int idx = 0;
/*
@@ -41,9 +49,9 @@ u32 get_module_plt(struct module *mod, u
* relocations are sorted, this will be the last entry we allocated.
* (if one exists).
*/
- if (mod->arch.plt_count > 0) {
- plt += (mod->arch.plt_count - 1) / PLT_ENT_COUNT;
- idx = (mod->arch.plt_count - 1) % PLT_ENT_COUNT;
+ if (pltsec->plt_count > 0) {
+ plt += (pltsec->plt_count - 1) / PLT_ENT_COUNT;
+ idx = (pltsec->plt_count - 1) % PLT_ENT_COUNT;
if (plt->lit[idx] == val)
return (u32)&plt->ldr[idx];
@@ -53,8 +61,8 @@ u32 get_module_plt(struct module *mod, u
plt++;
}
- mod->arch.plt_count++;
- BUG_ON(mod->arch.plt_count * PLT_ENT_SIZE > mod->arch.plt->sh_size);
+ pltsec->plt_count++;
+ BUG_ON(pltsec->plt_count * PLT_ENT_SIZE > pltsec->plt->sh_size);
if (!idx)
/* Populate a new set of entries */
@@ -129,7 +137,7 @@ static bool duplicate_rel(Elf32_Addr bas
/* Count how many PLT entries we may need */
static unsigned int count_plts(const Elf32_Sym *syms, Elf32_Addr base,
- const Elf32_Rel *rel, int num)
+ const Elf32_Rel *rel, int num, Elf32_Word dstidx)
{
unsigned int ret = 0;
const Elf32_Sym *s;
@@ -144,13 +152,17 @@ static unsigned int count_plts(const Elf
case R_ARM_THM_JUMP24:
/*
* We only have to consider branch targets that resolve
- * to undefined symbols. This is not simply a heuristic,
- * it is a fundamental limitation, since the PLT itself
- * is part of the module, and needs to be within range
- * as well, so modules can never grow beyond that limit.
+ * to symbols that are defined in a different section.
+ * This is not simply a heuristic, it is a fundamental
+ * limitation, since there is no guaranteed way to emit
+ * PLT entries sufficiently close to the branch if the
+ * section size exceeds the range of a branch
+ * instruction. So ignore relocations against defined
+ * symbols if they live in the same section as the
+ * relocation target.
*/
s = syms + ELF32_R_SYM(rel[i].r_info);
- if (s->st_shndx != SHN_UNDEF)
+ if (s->st_shndx == dstidx)
break;
/*
@@ -161,7 +173,12 @@ static unsigned int count_plts(const Elf
* So we need to support them, but there is no need to
* take them into consideration when trying to optimize
* this code. So let's only check for duplicates when
- * the addend is zero.
+ * the addend is zero. (Note that calls into the core
+ * module via init PLT entries could involve section
+ * relative symbol references with non-zero addends, for
+ * which we may end up emitting duplicates, but the init
+ * PLT is released along with the rest of the .init
+ * region as soon as module loading completes.)
*/
if (!is_zero_addend_relocation(base, rel + i) ||
!duplicate_rel(base, rel, i))
@@ -174,7 +191,8 @@ static unsigned int count_plts(const Elf
int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
char *secstrings, struct module *mod)
{
- unsigned long plts = 0;
+ unsigned long core_plts = 0;
+ unsigned long init_plts = 0;
Elf32_Shdr *s, *sechdrs_end = sechdrs + ehdr->e_shnum;
Elf32_Sym *syms = NULL;
@@ -184,13 +202,15 @@ int module_frob_arch_sections(Elf_Ehdr *
*/
for (s = sechdrs; s < sechdrs_end; ++s) {
if (strcmp(".plt", secstrings + s->sh_name) == 0)
- mod->arch.plt = s;
+ mod->arch.core.plt = s;
+ else if (strcmp(".init.plt", secstrings + s->sh_name) == 0)
+ mod->arch.init.plt = s;
else if (s->sh_type == SHT_SYMTAB)
syms = (Elf32_Sym *)s->sh_addr;
}
- if (!mod->arch.plt) {
- pr_err("%s: module PLT section missing\n", mod->name);
+ if (!mod->arch.core.plt || !mod->arch.init.plt) {
+ pr_err("%s: module PLT section(s) missing\n", mod->name);
return -ENOEXEC;
}
if (!syms) {
@@ -213,16 +233,29 @@ int module_frob_arch_sections(Elf_Ehdr *
/* sort by type and symbol index */
sort(rels, numrels, sizeof(Elf32_Rel), cmp_rel, NULL);
- plts += count_plts(syms, dstsec->sh_addr, rels, numrels);
+ if (strncmp(secstrings + dstsec->sh_name, ".init", 5) != 0)
+ core_plts += count_plts(syms, dstsec->sh_addr, rels,
+ numrels, s->sh_info);
+ else
+ init_plts += count_plts(syms, dstsec->sh_addr, rels,
+ numrels, s->sh_info);
}
- mod->arch.plt->sh_type = SHT_NOBITS;
- mod->arch.plt->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
- mod->arch.plt->sh_addralign = L1_CACHE_BYTES;
- mod->arch.plt->sh_size = round_up(plts * PLT_ENT_SIZE,
- sizeof(struct plt_entries));
- mod->arch.plt_count = 0;
+ mod->arch.core.plt->sh_type = SHT_NOBITS;
+ mod->arch.core.plt->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
+ mod->arch.core.plt->sh_addralign = L1_CACHE_BYTES;
+ mod->arch.core.plt->sh_size = round_up(core_plts * PLT_ENT_SIZE,
+ sizeof(struct plt_entries));
+ mod->arch.core.plt_count = 0;
+
+ mod->arch.init.plt->sh_type = SHT_NOBITS;
+ mod->arch.init.plt->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
+ mod->arch.init.plt->sh_addralign = L1_CACHE_BYTES;
+ mod->arch.init.plt->sh_size = round_up(init_plts * PLT_ENT_SIZE,
+ sizeof(struct plt_entries));
+ mod->arch.init.plt_count = 0;
- pr_debug("%s: plt=%x\n", __func__, mod->arch.plt->sh_size);
+ pr_debug("%s: plt=%x, init.plt=%x\n", __func__,
+ mod->arch.core.plt->sh_size, mod->arch.init.plt->sh_size);
return 0;
}
--- a/arch/arm/kernel/module.lds
+++ b/arch/arm/kernel/module.lds
@@ -1,3 +1,4 @@
SECTIONS {
.plt : { BYTE(0) }
+ .init.plt : { BYTE(0) }
}
Patches currently in stable-queue which might be from ard.biesheuvel@linaro.org are
queue-4.11/arm-8662-1-module-split-core-and-init-plt-sections.patch
queue-4.11/arm-8667-3-fix-memory-attribute-inconsistencies-when-using-fixmap.patch
^ permalink raw reply
* Patch "xc2028: Fix use-after-free bug properly" has been added to the 3.18-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tiwai, amit.pundir, gregkh, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
xc2028: Fix use-after-free bug properly
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xc2028-fix-use-after-free-bug-properly.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 22a1e7783e173ab3d86018eb590107d68df46c11 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Thu, 17 Nov 2016 10:49:31 +0100
Subject: xc2028: Fix use-after-free bug properly
From: Takashi Iwai <tiwai@suse.de>
commit 22a1e7783e173ab3d86018eb590107d68df46c11 upstream.
The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.
However, it's clearing the wrong pointer; it sets NULL to
priv->ctrl.fname, but it's anyway overwritten by the next line
memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
OTOH, the actual code accessing the freed string is the strcmp() call
with priv->fname:
if (!firmware_name[0] && p->fname &&
priv->fname && strcmp(p->fname, priv->fname))
free_firmware(priv);
where priv->fname points to the previous file name, and this was
already freed by kfree().
For fixing the bug properly, this patch does the following:
- Keep the copy of firmware file name in only priv->fname,
priv->ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly
Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/tuners/tuner-xc2028.c | 37 +++++++++++++++---------------------
1 file changed, 16 insertions(+), 21 deletions(-)
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -281,6 +281,14 @@ static void free_firmware(struct xc2028_
int i;
tuner_dbg("%s called\n", __func__);
+ /* free allocated f/w string */
+ if (priv->fname != firmware_name)
+ kfree(priv->fname);
+ priv->fname = NULL;
+
+ priv->state = XC2028_NO_FIRMWARE;
+ memset(&priv->cur_fw, 0, sizeof(priv->cur_fw));
+
if (!priv->firm)
return;
@@ -291,9 +299,6 @@ static void free_firmware(struct xc2028_
priv->firm = NULL;
priv->firm_size = 0;
- priv->state = XC2028_NO_FIRMWARE;
-
- memset(&priv->cur_fw, 0, sizeof(priv->cur_fw));
}
static int load_all_firmwares(struct dvb_frontend *fe,
@@ -884,9 +889,8 @@ read_not_reliable:
return 0;
fail:
- priv->state = XC2028_NO_FIRMWARE;
+ free_firmware(priv);
- memset(&priv->cur_fw, 0, sizeof(priv->cur_fw));
if (retry_count < 8) {
msleep(50);
retry_count++;
@@ -1332,11 +1336,8 @@ static int xc2028_dvb_release(struct dvb
mutex_lock(&xc2028_list_mutex);
/* only perform final cleanup if this is the last instance */
- if (hybrid_tuner_report_instance_count(priv) == 1) {
+ if (hybrid_tuner_report_instance_count(priv) == 1)
free_firmware(priv);
- kfree(priv->ctrl.fname);
- priv->ctrl.fname = NULL;
- }
if (priv)
hybrid_tuner_release_state(priv);
@@ -1399,19 +1400,8 @@ static int xc2028_set_config(struct dvb_
/*
* Copy the config data.
- * For the firmware name, keep a local copy of the string,
- * in order to avoid troubles during device release.
*/
- kfree(priv->ctrl.fname);
- priv->ctrl.fname = NULL;
memcpy(&priv->ctrl, p, sizeof(priv->ctrl));
- if (p->fname) {
- priv->ctrl.fname = kstrdup(p->fname, GFP_KERNEL);
- if (priv->ctrl.fname == NULL) {
- rc = -ENOMEM;
- goto unlock;
- }
- }
/*
* If firmware name changed, frees firmware. As free_firmware will
@@ -1426,10 +1416,15 @@ static int xc2028_set_config(struct dvb_
if (priv->state == XC2028_NO_FIRMWARE) {
if (!firmware_name[0])
- priv->fname = priv->ctrl.fname;
+ priv->fname = kstrdup(p->fname, GFP_KERNEL);
else
priv->fname = firmware_name;
+ if (!priv->fname) {
+ rc = -ENOMEM;
+ goto unlock;
+ }
+
rc = request_firmware_nowait(THIS_MODULE, 1,
priv->fname,
priv->i2c_props.adap->dev.parent,
Patches currently in stable-queue which might be from tiwai@suse.de are
queue-3.18/xc2028-fix-use-after-free-bug-properly.patch
^ permalink raw reply
* Patch "uwb: fix device quirk on big-endian hosts" has been added to the 3.18-stable tree
From: gregkh @ 2017-05-23 14:44 UTC (permalink / raw)
To: johan, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
uwb: fix device quirk on big-endian hosts
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
uwb-fix-device-quirk-on-big-endian-hosts.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 41318a2b82f5d5fe1fb408f6d6e0b22aa557111d Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Fri, 12 May 2017 12:06:32 +0200
Subject: uwb: fix device quirk on big-endian hosts
From: Johan Hovold <johan@kernel.org>
commit 41318a2b82f5d5fe1fb408f6d6e0b22aa557111d upstream.
Add missing endianness conversion when using the USB device-descriptor
idProduct field to apply a hardware quirk.
Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/uwb/i1480/dfu/usb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/uwb/i1480/dfu/usb.c
+++ b/drivers/uwb/i1480/dfu/usb.c
@@ -341,6 +341,7 @@ error_submit_ep1:
static
int i1480_usb_probe(struct usb_interface *iface, const struct usb_device_id *id)
{
+ struct usb_device *udev = interface_to_usbdev(iface);
struct i1480_usb *i1480_usb;
struct i1480 *i1480;
struct device *dev = &iface->dev;
@@ -352,8 +353,8 @@ int i1480_usb_probe(struct usb_interface
iface->cur_altsetting->desc.bInterfaceNumber);
goto error;
}
- if (iface->num_altsetting > 1
- && interface_to_usbdev(iface)->descriptor.idProduct == 0xbabe) {
+ if (iface->num_altsetting > 1 &&
+ le16_to_cpu(udev->descriptor.idProduct) == 0xbabe) {
/* Need altsetting #1 [HW QUIRK] or EP1 won't work */
result = usb_set_interface(interface_to_usbdev(iface), 0, 1);
if (result < 0)
Patches currently in stable-queue which might be from johan@kernel.org are
queue-3.18/cx231xx-audio-fix-null-deref-at-probe.patch
queue-3.18/usb-serial-io_ti-fix-div-by-zero-in-set_termios.patch
queue-3.18/usb-hub-fix-non-ss-hub-descriptor-handling.patch
queue-3.18/cx231xx-cards-fix-null-deref-at-probe.patch
queue-3.18/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-3.18/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-3.18/usb-iowarrior-fix-info-ioctl-on-big-endian-hosts.patch
queue-3.18/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-3.18/gspca-konica-add-missing-endpoint-sanity-check.patch
queue-3.18/usb-serial-qcserial-add-more-lenovo-em74xx-device-ids.patch
queue-3.18/usb-serial-option-add-telit-me910-support.patch
queue-3.18/net-irda-irda-usb-fix-firmware-name-on-big-endian-hosts.patch
queue-3.18/dib0700-fix-null-deref-at-probe.patch
queue-3.18/of-fdt-add-missing-allocation-failure-check.patch
queue-3.18/usbvision-fix-null-deref-at-probe.patch
queue-3.18/usb-serial-mct_u232-fix-big-endian-baud-rate-handling.patch
queue-3.18/uwb-fix-device-quirk-on-big-endian-hosts.patch
queue-3.18/mceusb-fix-null-deref-at-probe.patch
queue-3.18/usb-hub-fix-ss-hub-descriptor-handling.patch
queue-3.18/ath9k_htc-fix-null-deref-at-probe.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox