* FAILED: patch "[PATCH] kvm: arm/arm64: Force reading uncached stage2 PGD" failed to apply to 4.11-stable tree
From: gregkh @ 2017-05-23 14:27 UTC (permalink / raw)
To: suzuki.poulose, cdall, marc.zyngier; +Cc: stable
The patch below does not apply to the 4.11-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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 2952a6070e07ebdd5896f1f5b861acad677caded Mon Sep 17 00:00:00 2001
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Date: Tue, 16 May 2017 10:34:54 +0100
Subject: [PATCH] kvm: arm/arm64: Force reading uncached stage2 PGD
Make sure we don't use a cached value of the KVM stage2 PGD while
resetting the PGD.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 909a1a793b31..704e35f312a4 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -837,7 +837,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
spin_lock(&kvm->mmu_lock);
if (kvm->arch.pgd) {
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
- pgd = kvm->arch.pgd;
+ pgd = READ_ONCE(kvm->arch.pgd);
kvm->arch.pgd = NULL;
}
spin_unlock(&kvm->mmu_lock);
^ permalink raw reply related
* FAILED: patch "[PATCH] kvm: arm/arm64: Fix use after free of stage2 page table" failed to apply to 4.11-stable tree
From: gregkh @ 2017-05-23 14:26 UTC (permalink / raw)
To: suzuki.poulose, cdall, marc.zyngier, mark.rutland, pbonzini,
rkrcmar; +Cc: stable
The patch below does not apply to the 4.11-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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 0c428a6a9256fcd66817e12db32a50b405ed2e5c Mon Sep 17 00:00:00 2001
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Date: Tue, 16 May 2017 10:34:55 +0100
Subject: [PATCH] kvm: arm/arm64: Fix use after free of stage2 page table
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We yield the kvm->mmu_lock occassionaly while performing an operation
(e.g, unmap or permission changes) on a large area of stage2 mappings.
However this could possibly cause another thread to clear and free up
the stage2 page tables while we were waiting for regaining the lock and
thus the original thread could end up in accessing memory that was
freed. This patch fixes the problem by making sure that the stage2
pagetable is still valid after we regain the lock. The fact that
mmu_notifer->release() could be called twice (via __mmu_notifier_release
and mmu_notifier_unregsister) enhances the possibility of hitting
this race where there are two threads trying to unmap the entire guest
shadow pages.
While at it, cleanup the redudant checks around cond_resched_lock in
stage2_wp_range(), as cond_resched_lock already does the same checks.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: andreyknvl@google.com
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 704e35f312a4..a2d63247d1bb 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -295,6 +295,13 @@ static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
assert_spin_locked(&kvm->mmu_lock);
pgd = kvm->arch.pgd + stage2_pgd_index(addr);
do {
+ /*
+ * Make sure the page table is still active, as another thread
+ * could have possibly freed the page table, while we released
+ * the lock.
+ */
+ if (!READ_ONCE(kvm->arch.pgd))
+ break;
next = stage2_pgd_addr_end(addr, end);
if (!stage2_pgd_none(*pgd))
unmap_stage2_puds(kvm, pgd, addr, next);
@@ -1170,11 +1177,13 @@ static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr, phys_addr_t end)
* large. Otherwise, we may see kernel panics with
* CONFIG_DETECT_HUNG_TASK, CONFIG_LOCKUP_DETECTOR,
* CONFIG_LOCKDEP. Additionally, holding the lock too long
- * will also starve other vCPUs.
+ * will also starve other vCPUs. We have to also make sure
+ * that the page tables are not freed while we released
+ * the lock.
*/
- if (need_resched() || spin_needbreak(&kvm->mmu_lock))
- cond_resched_lock(&kvm->mmu_lock);
-
+ cond_resched_lock(&kvm->mmu_lock);
+ if (!READ_ONCE(kvm->arch.pgd))
+ break;
next = stage2_pgd_addr_end(addr, end);
if (stage2_pgd_present(*pgd))
stage2_wp_puds(pgd, addr, next);
^ permalink raw reply related
* FAILED: patch "[PATCH] powerpc/sysfs: Fix reference leak of cpu device_nodes present" failed to apply to 3.18-stable tree
From: gregkh @ 2017-05-23 14:23 UTC (permalink / raw)
To: tyreld, mpe; +Cc: stable
The patch below does not apply to the 3.18-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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e76ca27790a514590af782f83f6eae49e0ccf8c9 Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date: Mon, 17 Apr 2017 20:24:39 -0400
Subject: [PATCH] powerpc/sysfs: Fix reference leak of cpu device_nodes present
at boot
For CPUs present at boot each logical CPU acquires a reference to the
associated device node of the core. This happens in register_cpu() which
is called by topology_init(). The result of this is that we end up with
a reference held by each thread of the core. However, these references
are never freed if the CPU core is DLPAR removed.
This patch fixes the reference leaks by acquiring and releasing the references
in the CPU hotplug callbacks un/register_cpu_online(). With this patch symmetric
reference counting is observed with both CPUs present at boot, and those DLPAR
added after boot.
Fixes: f86e4718f24b ("driver/core: cpu: initialize of_node in cpu's device struture")
Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index c1fb255a60d6..949957b97ead 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -710,6 +710,10 @@ static int register_cpu_online(unsigned int cpu)
struct device_attribute *attrs, *pmc_attrs;
int i, nattrs;
+ /* For cpus present at boot a reference was already grabbed in register_cpu() */
+ if (!s->of_node)
+ s->of_node = of_get_cpu_node(cpu, NULL);
+
#ifdef CONFIG_PPC64
if (cpu_has_feature(CPU_FTR_SMT))
device_create_file(s, &dev_attr_smt_snooze_delay);
@@ -864,6 +868,8 @@ static int unregister_cpu_online(unsigned int cpu)
}
#endif
cacheinfo_cpu_offline(cpu);
+ of_node_put(s->of_node);
+ s->of_node = NULL;
#endif /* CONFIG_HOTPLUG_CPU */
return 0;
}
^ permalink raw reply related
* FAILED: patch "[PATCH] powerpc/sysfs: Fix reference leak of cpu device_nodes present" failed to apply to 4.4-stable tree
From: gregkh @ 2017-05-23 14:23 UTC (permalink / raw)
To: tyreld, mpe; +Cc: stable
The patch below does not apply to the 4.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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e76ca27790a514590af782f83f6eae49e0ccf8c9 Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date: Mon, 17 Apr 2017 20:24:39 -0400
Subject: [PATCH] powerpc/sysfs: Fix reference leak of cpu device_nodes present
at boot
For CPUs present at boot each logical CPU acquires a reference to the
associated device node of the core. This happens in register_cpu() which
is called by topology_init(). The result of this is that we end up with
a reference held by each thread of the core. However, these references
are never freed if the CPU core is DLPAR removed.
This patch fixes the reference leaks by acquiring and releasing the references
in the CPU hotplug callbacks un/register_cpu_online(). With this patch symmetric
reference counting is observed with both CPUs present at boot, and those DLPAR
added after boot.
Fixes: f86e4718f24b ("driver/core: cpu: initialize of_node in cpu's device struture")
Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index c1fb255a60d6..949957b97ead 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -710,6 +710,10 @@ static int register_cpu_online(unsigned int cpu)
struct device_attribute *attrs, *pmc_attrs;
int i, nattrs;
+ /* For cpus present at boot a reference was already grabbed in register_cpu() */
+ if (!s->of_node)
+ s->of_node = of_get_cpu_node(cpu, NULL);
+
#ifdef CONFIG_PPC64
if (cpu_has_feature(CPU_FTR_SMT))
device_create_file(s, &dev_attr_smt_snooze_delay);
@@ -864,6 +868,8 @@ static int unregister_cpu_online(unsigned int cpu)
}
#endif
cacheinfo_cpu_offline(cpu);
+ of_node_put(s->of_node);
+ s->of_node = NULL;
#endif /* CONFIG_HOTPLUG_CPU */
return 0;
}
^ permalink raw reply related
* FAILED: patch "[PATCH] powerpc/sysfs: Fix reference leak of cpu device_nodes present" failed to apply to 4.9-stable tree
From: gregkh @ 2017-05-23 14:23 UTC (permalink / raw)
To: tyreld, mpe; +Cc: stable
The patch below does not apply to the 4.9-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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e76ca27790a514590af782f83f6eae49e0ccf8c9 Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date: Mon, 17 Apr 2017 20:24:39 -0400
Subject: [PATCH] powerpc/sysfs: Fix reference leak of cpu device_nodes present
at boot
For CPUs present at boot each logical CPU acquires a reference to the
associated device node of the core. This happens in register_cpu() which
is called by topology_init(). The result of this is that we end up with
a reference held by each thread of the core. However, these references
are never freed if the CPU core is DLPAR removed.
This patch fixes the reference leaks by acquiring and releasing the references
in the CPU hotplug callbacks un/register_cpu_online(). With this patch symmetric
reference counting is observed with both CPUs present at boot, and those DLPAR
added after boot.
Fixes: f86e4718f24b ("driver/core: cpu: initialize of_node in cpu's device struture")
Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index c1fb255a60d6..949957b97ead 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -710,6 +710,10 @@ static int register_cpu_online(unsigned int cpu)
struct device_attribute *attrs, *pmc_attrs;
int i, nattrs;
+ /* For cpus present at boot a reference was already grabbed in register_cpu() */
+ if (!s->of_node)
+ s->of_node = of_get_cpu_node(cpu, NULL);
+
#ifdef CONFIG_PPC64
if (cpu_has_feature(CPU_FTR_SMT))
device_create_file(s, &dev_attr_smt_snooze_delay);
@@ -864,6 +868,8 @@ static int unregister_cpu_online(unsigned int cpu)
}
#endif
cacheinfo_cpu_offline(cpu);
+ of_node_put(s->of_node);
+ s->of_node = NULL;
#endif /* CONFIG_HOTPLUG_CPU */
return 0;
}
^ permalink raw reply related
* FAILED: patch "[PATCH] powerpc/eeh: Avoid use after free in" failed to apply to 3.18-stable tree
From: gregkh @ 2017-05-23 14:22 UTC (permalink / raw)
To: ruscur, aik, gwshan, mpe; +Cc: stable
The patch below does not apply to the 3.18-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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From daeba2956f32f91f3493788ff6ee02fb1b2f02fa Mon Sep 17 00:00:00 2001
From: Russell Currey <ruscur@russell.cc>
Date: Wed, 19 Apr 2017 17:39:26 +1000
Subject: [PATCH] powerpc/eeh: Avoid use after free in
eeh_handle_special_event()
eeh_handle_special_event() is called when an EEH event is detected but
can't be narrowed down to a specific PE. This function looks through
every PE to find one in an erroneous state, then calls the regular event
handler eeh_handle_normal_event() once it knows which PE has an error.
However, if eeh_handle_normal_event() found that the PE cannot possibly
be recovered, it will free it, rendering the passed PE stale.
This leads to a use after free in eeh_handle_special_event() as it attempts to
clear the "recovering" state on the PE after eeh_handle_normal_event() returns.
Thus, make sure the PE is valid when attempting to clear state in
eeh_handle_special_event().
Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event")
Cc: stable@vger.kernel.org # v3.11+
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index b94887165a10..e50d1470714f 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -724,7 +724,7 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus,
*/
#define MAX_WAIT_FOR_RECOVERY 300
-static void eeh_handle_normal_event(struct eeh_pe *pe)
+static bool eeh_handle_normal_event(struct eeh_pe *pe)
{
struct pci_bus *frozen_bus;
struct eeh_dev *edev, *tmp;
@@ -736,7 +736,7 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
if (!frozen_bus) {
pr_err("%s: Cannot find PCI bus for PHB#%x-PE#%x\n",
__func__, pe->phb->global_number, pe->addr);
- return;
+ return false;
}
eeh_pe_update_time_stamp(pe);
@@ -870,7 +870,7 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
pr_info("EEH: Notify device driver to resume\n");
eeh_pe_dev_traverse(pe, eeh_report_resume, NULL);
- return;
+ return false;
excess_failures:
/*
@@ -915,8 +915,12 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
pci_lock_rescan_remove();
pci_hp_remove_devices(frozen_bus);
pci_unlock_rescan_remove();
+
+ /* The passed PE should no longer be used */
+ return true;
}
}
+ return false;
}
static void eeh_handle_special_event(void)
@@ -982,7 +986,14 @@ static void eeh_handle_special_event(void)
*/
if (rc == EEH_NEXT_ERR_FROZEN_PE ||
rc == EEH_NEXT_ERR_FENCED_PHB) {
- eeh_handle_normal_event(pe);
+ /*
+ * eeh_handle_normal_event() can make the PE stale if it
+ * determines that the PE cannot possibly be recovered.
+ * Don't modify the PE state if that's the case.
+ */
+ if (eeh_handle_normal_event(pe))
+ continue;
+
eeh_pe_state_clear(pe, EEH_PE_RECOVERING);
} else {
pci_lock_rescan_remove();
^ permalink raw reply related
* FAILED: patch "[PATCH] powerpc/eeh: Avoid use after free in" failed to apply to 4.4-stable tree
From: gregkh @ 2017-05-23 14:22 UTC (permalink / raw)
To: ruscur, aik, gwshan, mpe; +Cc: stable
The patch below does not apply to the 4.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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From daeba2956f32f91f3493788ff6ee02fb1b2f02fa Mon Sep 17 00:00:00 2001
From: Russell Currey <ruscur@russell.cc>
Date: Wed, 19 Apr 2017 17:39:26 +1000
Subject: [PATCH] powerpc/eeh: Avoid use after free in
eeh_handle_special_event()
eeh_handle_special_event() is called when an EEH event is detected but
can't be narrowed down to a specific PE. This function looks through
every PE to find one in an erroneous state, then calls the regular event
handler eeh_handle_normal_event() once it knows which PE has an error.
However, if eeh_handle_normal_event() found that the PE cannot possibly
be recovered, it will free it, rendering the passed PE stale.
This leads to a use after free in eeh_handle_special_event() as it attempts to
clear the "recovering" state on the PE after eeh_handle_normal_event() returns.
Thus, make sure the PE is valid when attempting to clear state in
eeh_handle_special_event().
Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event")
Cc: stable@vger.kernel.org # v3.11+
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index b94887165a10..e50d1470714f 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -724,7 +724,7 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus,
*/
#define MAX_WAIT_FOR_RECOVERY 300
-static void eeh_handle_normal_event(struct eeh_pe *pe)
+static bool eeh_handle_normal_event(struct eeh_pe *pe)
{
struct pci_bus *frozen_bus;
struct eeh_dev *edev, *tmp;
@@ -736,7 +736,7 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
if (!frozen_bus) {
pr_err("%s: Cannot find PCI bus for PHB#%x-PE#%x\n",
__func__, pe->phb->global_number, pe->addr);
- return;
+ return false;
}
eeh_pe_update_time_stamp(pe);
@@ -870,7 +870,7 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
pr_info("EEH: Notify device driver to resume\n");
eeh_pe_dev_traverse(pe, eeh_report_resume, NULL);
- return;
+ return false;
excess_failures:
/*
@@ -915,8 +915,12 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
pci_lock_rescan_remove();
pci_hp_remove_devices(frozen_bus);
pci_unlock_rescan_remove();
+
+ /* The passed PE should no longer be used */
+ return true;
}
}
+ return false;
}
static void eeh_handle_special_event(void)
@@ -982,7 +986,14 @@ static void eeh_handle_special_event(void)
*/
if (rc == EEH_NEXT_ERR_FROZEN_PE ||
rc == EEH_NEXT_ERR_FENCED_PHB) {
- eeh_handle_normal_event(pe);
+ /*
+ * eeh_handle_normal_event() can make the PE stale if it
+ * determines that the PE cannot possibly be recovered.
+ * Don't modify the PE state if that's the case.
+ */
+ if (eeh_handle_normal_event(pe))
+ continue;
+
eeh_pe_state_clear(pe, EEH_PE_RECOVERING);
} else {
pci_lock_rescan_remove();
^ permalink raw reply related
* Re: Patch "drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one" has been added to the 4.9-stable tree
From: Greg Kroah-Hartman @ 2017-05-23 14:20 UTC (permalink / raw)
To: Ilia Mirkin; +Cc: Ben Skeggs, # 3.9+, stable-commits
In-Reply-To: <CAKb7UvjhV9vBuKwospufvk7f0WcVXaz9tZhcVF0Lav-TUVM+GQ@mail.gmail.com>
On Tue, May 23, 2017 at 10:04:58AM -0400, Ilia Mirkin wrote:
> On Tue, May 23, 2017 at 5:30 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, May 22, 2017 at 07:49:50PM -0400, Ilia Mirkin wrote:
> >> On Mon, May 22, 2017 at 6:57 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> >> > Hi Greg,
> >> >
> >> > This patch appears to have misapplied. I'm not sure why cherry-pick
> >> > got it wrong, but this is meant to go in the nv4a_chipset definition,
> >> > not nv44_chipset.
> >> >
> >> > This comment also applies to the 4.4 and 4.11 cherry-picks you just did.
> >>
> >> Aha, I see what happened. f94773b9f5ecd1df7c88c2e921924dd41d2020cc
> >> made it into v4.11. However by then it appears to have also made it
> >> into drm-next as ac799acaa4d8db4f7dcd968b15c9596c80a4677f and thus the
> >> drm merge into v4.12. So now you have two versions of the same commit
> >> and are trying to cherry-pick both.
> >
> > Why in the world would you include the same patch in two different trees
> > with two different git ids? I'm _really_ starting to hate the drm
> > trees...
>
> This question may be above my pay-grade (I'm just a lowly occasional
> contributor), but I believe the situation is that first the change
> goes into drm-next, and then is cherry-picked into drm-fixes. I
> haven't checked that this is what happened though. Nor am I
> sufficiently plugged into linux kernel development processes to know
> what the proper way to handle that situation would be, if any.
> Something to address with Ben Skeggs and Dave Airlie, I suppose.
It seems that the i915 model of putting duplicate patches in different
branches is seeping over into other drm driver trees :(
The people involved with that know my position there, it's a pain in the
ass for people like me, for reasons exactly like you are seeing here.
Thanks for helping out with this.
> >> I'm guessing it's also the reason why your cherrypick of my other
> >> commit failed (ad01a91a820cd9f0d880c407bf556b67298dcc93).
> >
> > That would make sense, but again, why is this happening?
> >
> >> And I might note that
> >> "drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch" was
> >> already there before, so didn't make it into your "4.9-stable patches"
> >> commit on the stable-queue git tree.
> >
> > Ok, so what should i do here? Drop all of the nouveau patches? Some of
> > them? Which ones were wrong?
>
> Looking at e.g.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.9
>
> I can say unequivocally that
> "drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch" is
> wrong in all three of your queues (4.4, 4.9, 4.11). Please drop it.
Ok, now all dropped.
thanks again for catching this and letting me know what to do,
greg k-h
^ permalink raw reply
* Re: Patch "drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one" has been added to the 4.9-stable tree
From: Ilia Mirkin @ 2017-05-23 14:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Ben Skeggs, # 3.9+, stable-commits
In-Reply-To: <20170523093044.GE22923@kroah.com>
On Tue, May 23, 2017 at 5:30 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, May 22, 2017 at 07:49:50PM -0400, Ilia Mirkin wrote:
>> On Mon, May 22, 2017 at 6:57 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>> > Hi Greg,
>> >
>> > This patch appears to have misapplied. I'm not sure why cherry-pick
>> > got it wrong, but this is meant to go in the nv4a_chipset definition,
>> > not nv44_chipset.
>> >
>> > This comment also applies to the 4.4 and 4.11 cherry-picks you just did.
>>
>> Aha, I see what happened. f94773b9f5ecd1df7c88c2e921924dd41d2020cc
>> made it into v4.11. However by then it appears to have also made it
>> into drm-next as ac799acaa4d8db4f7dcd968b15c9596c80a4677f and thus the
>> drm merge into v4.12. So now you have two versions of the same commit
>> and are trying to cherry-pick both.
>
> Why in the world would you include the same patch in two different trees
> with two different git ids? I'm _really_ starting to hate the drm
> trees...
This question may be above my pay-grade (I'm just a lowly occasional
contributor), but I believe the situation is that first the change
goes into drm-next, and then is cherry-picked into drm-fixes. I
haven't checked that this is what happened though. Nor am I
sufficiently plugged into linux kernel development processes to know
what the proper way to handle that situation would be, if any.
Something to address with Ben Skeggs and Dave Airlie, I suppose.
>
>> I'm guessing it's also the reason why your cherrypick of my other
>> commit failed (ad01a91a820cd9f0d880c407bf556b67298dcc93).
>
> That would make sense, but again, why is this happening?
>
>> And I might note that
>> "drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch" was
>> already there before, so didn't make it into your "4.9-stable patches"
>> commit on the stable-queue git tree.
>
> Ok, so what should i do here? Drop all of the nouveau patches? Some of
> them? Which ones were wrong?
Looking at e.g.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.9
I can say unequivocally that
"drm-nouveau-mmu-nv4a-use-nv04-mmu-rather-than-the-nv44-one.patch" is
wrong in all three of your queues (4.4, 4.9, 4.11). Please drop it.
AFAIK the others should be good, but they're not my patches.
Cheers,
-ilia
^ permalink raw reply
* Re: FAILED: patch "[PATCH] [media] dvb-usb-firmware: don't do DMA on stack" failed to apply to 4.11-stable tree
From: gregkh @ 2017-05-23 13:54 UTC (permalink / raw)
To: Brüns, Stefan; +Cc: stable@vger.kernel.org, mchehab@s-opensource.com
In-Reply-To: <2206542.kVfVQDmVMf@sbruens-linux>
On Tue, May 23, 2017 at 01:28:07PM +0000, Br�ns, Stefan wrote:
> On Dienstag, 23. Mai 2017 14:33:55 CEST gregkh@linuxfoundation.org wrote:
> > The patch below does not apply to the 4.11-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@vger.kernel.org>.
>
> Please apply this:
> 67b0503db9c29b04eadfeede6bebbfe5ddad94ef ("[media] dvb-usb-firmware: don't do
> DMA on stack")
Wait, that's a different commit id! That's already in 4.11.
>
> on top of commit:
> 43fab9793c1f44e665b4f98035a14942edf03ddc ("[media] dvb-usb: don't use stack
> for firmware load")
As is this one.
So I guess there's nothing to do here, right?
thanks,
greg k-h
^ permalink raw reply
* Patch "[media] s5p-mfc: Fix unbalanced call to clock management" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: m.szyprowski, gregkh, mchehab, s.nawrocki; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] s5p-mfc: Fix unbalanced call to clock management
to the 4.9-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:
s5p-mfc-fix-unbalanced-call-to-clock-management.patch
and it can be found in the queue-4.9 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 a5cb00eb4223458250b55daf03ac7ea5f424d601 Mon Sep 17 00:00:00 2001
From: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Wed, 22 Mar 2017 04:53:57 -0300
Subject: [media] s5p-mfc: Fix unbalanced call to clock management
From: Marek Szyprowski <m.szyprowski@samsung.com>
commit a5cb00eb4223458250b55daf03ac7ea5f424d601 upstream.
Clock should be turned off after calling s5p_mfc_init_hw() from the
watchdog worker, like it is already done in the s5p_mfc_open() which also
calls this function.
Fixes: af93574678108 ("[media] MFC: Add MFC 5.1 V4L2 driver")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -206,6 +206,7 @@ static void s5p_mfc_watchdog_worker(stru
}
s5p_mfc_clock_on();
ret = s5p_mfc_init_hw(dev);
+ s5p_mfc_clock_off();
if (ret)
mfc_err("Failed to reinit FW\n");
}
Patches currently in stable-queue which might be from m.szyprowski@samsung.com are
queue-4.9/s5p-mfc-fix-race-between-interrupt-routine-and-device-functions.patch
queue-4.9/s5p-mfc-fix-unbalanced-call-to-clock-management.patch
^ permalink raw reply
* Patch "[media] zr364xx: enforce minimum size when reading header" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: amilburn, gregkh, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] zr364xx: enforce minimum size when reading header
to the 4.9-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:
zr364xx-enforce-minimum-size-when-reading-header.patch
and it can be found in the queue-4.9 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 ee0fe833d96793853335844b6d99fb76bd12cbeb Mon Sep 17 00:00:00 2001
From: Alyssa Milburn <amilburn@zall.org>
Date: Sat, 1 Apr 2017 14:34:08 -0300
Subject: [media] zr364xx: enforce minimum size when reading header
From: Alyssa Milburn <amilburn@zall.org>
commit ee0fe833d96793853335844b6d99fb76bd12cbeb upstream.
This code copies actual_length-128 bytes from the header, which will
underflow if the received buffer is too small.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/zr364xx/zr364xx.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/media/usb/zr364xx/zr364xx.c
+++ b/drivers/media/usb/zr364xx/zr364xx.c
@@ -604,6 +604,14 @@ static int zr364xx_read_video_callback(s
ptr = pdest = frm->lpvbits;
if (frm->ulState == ZR364XX_READ_IDLE) {
+ if (purb->actual_length < 128) {
+ /* header incomplete */
+ dev_info(&cam->udev->dev,
+ "%s: buffer (%d bytes) too small to hold jpeg header. Discarding.\n",
+ __func__, purb->actual_length);
+ return -EINVAL;
+ }
+
frm->ulState = ZR364XX_READ_FRAME;
frm->cur_size = 0;
Patches currently in stable-queue which might be from amilburn@zall.org are
queue-4.9/digitv-limit-messages-to-buffer-size.patch
queue-4.9/ttusb2-limit-messages-to-buffer-size.patch
queue-4.9/zr364xx-enforce-minimum-size-when-reading-header.patch
queue-4.9/dw2102-limit-messages-to-buffer-size.patch
^ permalink raw reply
* Patch "ipx: call ipxitf_put() in ioctl error path" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: dan.carpenter, davem, gregkh, liqiang6-s; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ipx: call ipxitf_put() in ioctl error path
to the 4.9-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:
ipx-call-ipxitf_put-in-ioctl-error-path.patch
and it can be found in the queue-4.9 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 ee0d8d8482345ff97a75a7d747efc309f13b0d80 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 2 May 2017 13:58:53 +0300
Subject: ipx: call ipxitf_put() in ioctl error path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dan Carpenter <dan.carpenter@oracle.com>
commit ee0d8d8482345ff97a75a7d747efc309f13b0d80 upstream.
We should call ipxitf_put() if the copy_to_user() fails.
Reported-by: 李强 <liqiang6-s@360.cn>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipx/af_ipx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1168,11 +1168,10 @@ static int ipxitf_ioctl(unsigned int cmd
sipx->sipx_network = ipxif->if_netnum;
memcpy(sipx->sipx_node, ipxif->if_node,
sizeof(sipx->sipx_node));
- rc = -EFAULT;
+ rc = 0;
if (copy_to_user(arg, &ifr, sizeof(ifr)))
- break;
+ rc = -EFAULT;
ipxitf_put(ipxif);
- rc = 0;
break;
}
case SIOCAIPXITFCRT:
Patches currently in stable-queue which might be from dan.carpenter@oracle.com are
queue-4.9/ipx-call-ipxitf_put-in-ioctl-error-path.patch
^ permalink raw reply
* Patch "[media] s5p-mfc: Fix race between interrupt routine and device functions" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: m.szyprowski; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] s5p-mfc: Fix race between interrupt routine and device functions
to the 4.9-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:
s5p-mfc-fix-race-between-interrupt-routine-and-device-functions.patch
and it can be found in the queue-4.9 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 0c32b8ec02832df167e16ad659cb11dc148f2ddf Mon Sep 17 00:00:00 2001
From: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Thu, 23 Feb 2017 08:43:27 -0300
Subject: [media] s5p-mfc: Fix race between interrupt routine and device functions
From: Marek Szyprowski <m.szyprowski@samsung.com>
commit 0c32b8ec02832df167e16ad659cb11dc148f2ddf upstream.
Interrupt routine must wake process waiting for given interrupt AFTER
updating driver's internal structures and contexts. Doing it in-between
is a serious bug. This patch moves all calls to the wake() function to
the end of the interrupt processing block to avoid potential and real
races, especially on multi-core platforms. This also fixes following issue
reported from clock core (clocks were disabled in interrupt after being
unprepared from the other place in the driver, the stack trace however
points to the different place than s5p_mfc driver because of the race):
WARNING: CPU: 1 PID: 18 at drivers/clk/clk.c:544 clk_core_unprepare+0xc8/0x108
Modules linked in:
CPU: 1 PID: 18 Comm: kworker/1:0 Not tainted 4.10.0-next-20170223-00070-g04e18bc99ab9-dirty #2154
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: pm pm_runtime_work
[<c010d8b0>] (unwind_backtrace) from [<c010a534>] (show_stack+0x10/0x14)
[<c010a534>] (show_stack) from [<c033292c>] (dump_stack+0x74/0x94)
[<c033292c>] (dump_stack) from [<c011cef4>] (__warn+0xd4/0x100)
[<c011cef4>] (__warn) from [<c011cf40>] (warn_slowpath_null+0x20/0x28)
[<c011cf40>] (warn_slowpath_null) from [<c0387a84>] (clk_core_unprepare+0xc8/0x108)
[<c0387a84>] (clk_core_unprepare) from [<c0389d84>] (clk_unprepare+0x24/0x2c)
[<c0389d84>] (clk_unprepare) from [<c03d4660>] (exynos_sysmmu_suspend+0x48/0x60)
[<c03d4660>] (exynos_sysmmu_suspend) from [<c042b9b0>] (pm_generic_runtime_suspend+0x2c/0x38)
[<c042b9b0>] (pm_generic_runtime_suspend) from [<c0437580>] (genpd_runtime_suspend+0x94/0x220)
[<c0437580>] (genpd_runtime_suspend) from [<c042e240>] (__rpm_callback+0x134/0x208)
[<c042e240>] (__rpm_callback) from [<c042e334>] (rpm_callback+0x20/0x80)
[<c042e334>] (rpm_callback) from [<c042d3b8>] (rpm_suspend+0xdc/0x458)
[<c042d3b8>] (rpm_suspend) from [<c042ea24>] (pm_runtime_work+0x80/0x90)
[<c042ea24>] (pm_runtime_work) from [<c01322c4>] (process_one_work+0x120/0x318)
[<c01322c4>] (process_one_work) from [<c0132520>] (worker_thread+0x2c/0x4ac)
[<c0132520>] (worker_thread) from [<c0137ab0>] (kthread+0xfc/0x134)
[<c0137ab0>] (kthread) from [<c0107978>] (ret_from_fork+0x14/0x3c)
---[ end trace 1ead49a7bb83f0d8 ]---
Fixes: af93574678108 ("[media] MFC: Add MFC 5.1 V4L2 driver")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -663,9 +663,9 @@ static irqreturn_t s5p_mfc_irq(int irq,
break;
}
s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
- wake_up_ctx(ctx, reason, err);
WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
s5p_mfc_clock_off();
+ wake_up_ctx(ctx, reason, err);
s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
} else {
s5p_mfc_handle_frame(ctx, reason, err);
@@ -679,15 +679,11 @@ static irqreturn_t s5p_mfc_irq(int irq,
case S5P_MFC_R2H_CMD_OPEN_INSTANCE_RET:
ctx->inst_no = s5p_mfc_hw_call(dev->mfc_ops, get_inst_no, dev);
ctx->state = MFCINST_GOT_INST;
- clear_work_bit(ctx);
- wake_up(&ctx->queue);
goto irq_cleanup_hw;
case S5P_MFC_R2H_CMD_CLOSE_INSTANCE_RET:
- clear_work_bit(ctx);
ctx->inst_no = MFC_NO_INSTANCE_SET;
ctx->state = MFCINST_FREE;
- wake_up(&ctx->queue);
goto irq_cleanup_hw;
case S5P_MFC_R2H_CMD_SYS_INIT_RET:
@@ -697,9 +693,9 @@ static irqreturn_t s5p_mfc_irq(int irq,
if (ctx)
clear_work_bit(ctx);
s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
- wake_up_dev(dev, reason, err);
clear_bit(0, &dev->hw_lock);
clear_bit(0, &dev->enter_suspend);
+ wake_up_dev(dev, reason, err);
break;
case S5P_MFC_R2H_CMD_INIT_BUFFERS_RET:
@@ -714,9 +710,7 @@ static irqreturn_t s5p_mfc_irq(int irq,
break;
case S5P_MFC_R2H_CMD_DPB_FLUSH_RET:
- clear_work_bit(ctx);
ctx->state = MFCINST_RUNNING;
- wake_up(&ctx->queue);
goto irq_cleanup_hw;
default:
@@ -735,6 +729,8 @@ irq_cleanup_hw:
mfc_err("Failed to unlock hw\n");
s5p_mfc_clock_off();
+ clear_work_bit(ctx);
+ wake_up(&ctx->queue);
s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
spin_unlock(&dev->irqlock);
Patches currently in stable-queue which might be from m.szyprowski@samsung.com are
queue-4.9/s5p-mfc-fix-race-between-interrupt-routine-and-device-functions.patch
queue-4.9/s5p-mfc-fix-unbalanced-call-to-clock-management.patch
^ permalink raw reply
* Patch "iio: hid-sensor: Store restore poll and hysteresis on S3" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: srinivas.pandruvada, gregkh, hongyan.song, jic23, rrs
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iio: hid-sensor: Store restore poll and hysteresis on S3
to the 4.9-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:
iio-hid-sensor-store-restore-poll-and-hysteresis-on-s3.patch
and it can be found in the queue-4.9 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 5d9854eaea776441b38a9a45b4e6879524c4f48c Mon Sep 17 00:00:00 2001
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date: Fri, 7 Apr 2017 17:13:17 -0700
Subject: iio: hid-sensor: Store restore poll and hysteresis on S3
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
commit 5d9854eaea776441b38a9a45b4e6879524c4f48c upstream.
This change undo the change done by 'commit 3bec24747446
("iio: hid-sensor-trigger: Change get poll value function order to avoid
sensor properties losing after resume from S3")' as this breaks some
USB/i2c sensor hubs.
Instead of relying on HW for restoring poll and hysteresis, driver stores
and restores on resume (S3). In this way user space modified settings are
not lost for any kind of sensor hub behavior.
In this change, whenever user space modifies sampling frequency or
hysteresis driver will get the feature value from the hub and store in the
per device hid_sensor_common data structure. On resume callback from S3,
system will set the feature to sensor hub, if user space ever modified the
feature value.
Fixes: 3bec24747446 ("iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3")
Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Song, Hongyan <hongyan.song@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 26 +++++++++++++++--
drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 20 +++++++++++--
include/linux/hid-sensor-hub.h | 2 +
3 files changed, 43 insertions(+), 5 deletions(-)
--- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
@@ -217,7 +217,15 @@ int hid_sensor_write_samp_freq_value(str
if (ret < 0 || value < 0)
ret = -EINVAL;
- return ret;
+ ret = sensor_hub_get_feature(st->hsdev,
+ st->poll.report_id,
+ st->poll.index, sizeof(value), &value);
+ if (ret < 0 || value < 0)
+ return -EINVAL;
+
+ st->poll_interval = value;
+
+ return 0;
}
EXPORT_SYMBOL(hid_sensor_write_samp_freq_value);
@@ -259,7 +267,16 @@ int hid_sensor_write_raw_hyst_value(stru
if (ret < 0 || value < 0)
ret = -EINVAL;
- return ret;
+ ret = sensor_hub_get_feature(st->hsdev,
+ st->sensitivity.report_id,
+ st->sensitivity.index, sizeof(value),
+ &value);
+ if (ret < 0 || value < 0)
+ return -EINVAL;
+
+ st->raw_hystersis = value;
+
+ return 0;
}
EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);
@@ -355,6 +372,9 @@ int hid_sensor_get_reporting_interval(st
/* Default unit of measure is milliseconds */
if (st->poll.units == 0)
st->poll.units = HID_USAGE_SENSOR_UNITS_MILLISECOND;
+
+ st->poll_interval = -1;
+
return 0;
}
@@ -377,6 +397,8 @@ int hid_sensor_parse_common_attributes(s
HID_USAGE_SENSOR_PROY_POWER_STATE,
&st->power_state);
+ st->raw_hystersis = -1;
+
sensor_hub_input_get_attribute_info(hsdev,
HID_FEATURE_REPORT, usage_id,
HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS,
--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
@@ -51,6 +51,8 @@ static int _hid_sensor_power_state(struc
st->report_state.report_id,
st->report_state.index,
HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM);
+
+ poll_value = hid_sensor_read_poll_value(st);
} else {
int val;
@@ -87,9 +89,7 @@ static int _hid_sensor_power_state(struc
sensor_hub_get_feature(st->hsdev, st->power_state.report_id,
st->power_state.index,
sizeof(state_val), &state_val);
- if (state)
- poll_value = hid_sensor_read_poll_value(st);
- if (poll_value > 0)
+ if (state && poll_value)
msleep_interruptible(poll_value * 2);
return 0;
@@ -127,6 +127,20 @@ static void hid_sensor_set_power_work(st
struct hid_sensor_common *attrb = container_of(work,
struct hid_sensor_common,
work);
+
+ if (attrb->poll_interval >= 0)
+ sensor_hub_set_feature(attrb->hsdev, attrb->poll.report_id,
+ attrb->poll.index,
+ sizeof(attrb->poll_interval),
+ &attrb->poll_interval);
+
+ if (attrb->raw_hystersis >= 0)
+ sensor_hub_set_feature(attrb->hsdev,
+ attrb->sensitivity.report_id,
+ attrb->sensitivity.index,
+ sizeof(attrb->raw_hystersis),
+ &attrb->raw_hystersis);
+
_hid_sensor_power_state(attrb, true);
}
--- a/include/linux/hid-sensor-hub.h
+++ b/include/linux/hid-sensor-hub.h
@@ -231,6 +231,8 @@ struct hid_sensor_common {
unsigned usage_id;
atomic_t data_ready;
atomic_t user_requested_state;
+ int poll_interval;
+ int raw_hystersis;
struct iio_trigger *trigger;
struct hid_sensor_hub_attribute_info poll;
struct hid_sensor_hub_attribute_info report_state;
Patches currently in stable-queue which might be from srinivas.pandruvada@linux.intel.com are
queue-4.9/iio-hid-sensor-store-restore-poll-and-hysteresis-on-s3.patch
^ permalink raw reply
* Patch "iio: proximity: as3935: fix as3935_write" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: matt.ranostay, george.mccollister, gregkh, jic23; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iio: proximity: as3935: fix as3935_write
to the 4.9-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:
iio-proximity-as3935-fix-as3935_write.patch
and it can be found in the queue-4.9 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 84ca8e364acb26aba3292bc113ca8ed4335380fd Mon Sep 17 00:00:00 2001
From: Matt Ranostay <matt.ranostay@konsulko.com>
Date: Thu, 13 Apr 2017 23:21:56 -0700
Subject: iio: proximity: as3935: fix as3935_write
From: Matt Ranostay <matt.ranostay@konsulko.com>
commit 84ca8e364acb26aba3292bc113ca8ed4335380fd upstream.
AS3935_WRITE_DATA macro bit is incorrect and the actual write
sequence is two leading zeros.
Cc: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/proximity/as3935.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/iio/proximity/as3935.c
+++ b/drivers/iio/proximity/as3935.c
@@ -50,7 +50,6 @@
#define AS3935_TUNE_CAP 0x08
#define AS3935_CALIBRATE 0x3D
-#define AS3935_WRITE_DATA BIT(15)
#define AS3935_READ_DATA BIT(14)
#define AS3935_ADDRESS(x) ((x) << 8)
@@ -105,7 +104,7 @@ static int as3935_write(struct as3935_st
{
u8 *buf = st->buf;
- buf[0] = (AS3935_WRITE_DATA | AS3935_ADDRESS(reg)) >> 8;
+ buf[0] = AS3935_ADDRESS(reg) >> 8;
buf[1] = val;
return spi_write(st->spi, buf, 2);
Patches currently in stable-queue which might be from matt.ranostay@konsulko.com are
queue-4.9/iio-proximity-as3935-fix-as3935_write.patch
queue-4.9/iio-bmp280-core.c-fix-error-in-humidity-calculation.patch
^ permalink raw reply
* Patch "[media] dw2102: limit messages to buffer size" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: amilburn, gregkh, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] dw2102: limit messages to buffer size
to the 4.9-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:
dw2102-limit-messages-to-buffer-size.patch
and it can be found in the queue-4.9 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 950e252cb469f323740d78e4907843acef89eedb Mon Sep 17 00:00:00 2001
From: Alyssa Milburn <amilburn@zall.org>
Date: Sat, 1 Apr 2017 14:34:49 -0300
Subject: [media] dw2102: limit messages to buffer size
From: Alyssa Milburn <amilburn@zall.org>
commit 950e252cb469f323740d78e4907843acef89eedb upstream.
Otherwise the i2c transfer functions can read or write beyond the end of
stack or heap buffers.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb/dw2102.c | 54 +++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -205,6 +205,20 @@ static int dw2102_serit_i2c_transfer(str
switch (num) {
case 2:
+ if (msg[0].len != 1) {
+ warn("i2c rd: len=%d is not 1!\n",
+ msg[0].len);
+ num = -EOPNOTSUPP;
+ break;
+ }
+
+ if (2 + msg[1].len > sizeof(buf6)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[1].len);
+ num = -EOPNOTSUPP;
+ break;
+ }
+
/* read si2109 register by number */
buf6[0] = msg[0].addr << 1;
buf6[1] = msg[0].len;
@@ -220,6 +234,13 @@ static int dw2102_serit_i2c_transfer(str
case 1:
switch (msg[0].addr) {
case 0x68:
+ if (2 + msg[0].len > sizeof(buf6)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[0].len);
+ num = -EOPNOTSUPP;
+ break;
+ }
+
/* write to si2109 register */
buf6[0] = msg[0].addr << 1;
buf6[1] = msg[0].len;
@@ -263,6 +284,13 @@ static int dw2102_earda_i2c_transfer(str
/* first write first register number */
u8 ibuf[MAX_XFER_SIZE], obuf[3];
+ if (2 + msg[0].len != sizeof(obuf)) {
+ warn("i2c rd: len=%d is not 1!\n",
+ msg[0].len);
+ ret = -EOPNOTSUPP;
+ goto unlock;
+ }
+
if (2 + msg[1].len > sizeof(ibuf)) {
warn("i2c rd: len=%d is too big!\n",
msg[1].len);
@@ -463,6 +491,12 @@ static int dw3101_i2c_transfer(struct i2
/* first write first register number */
u8 ibuf[MAX_XFER_SIZE], obuf[3];
+ if (2 + msg[0].len != sizeof(obuf)) {
+ warn("i2c rd: len=%d is not 1!\n",
+ msg[0].len);
+ ret = -EOPNOTSUPP;
+ goto unlock;
+ }
if (2 + msg[1].len > sizeof(ibuf)) {
warn("i2c rd: len=%d is too big!\n",
msg[1].len);
@@ -697,6 +731,13 @@ static int su3000_i2c_transfer(struct i2
msg[0].buf[0] = state->data[1];
break;
default:
+ if (3 + msg[0].len > sizeof(state->data)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[0].len);
+ num = -EOPNOTSUPP;
+ break;
+ }
+
/* always i2c write*/
state->data[0] = 0x08;
state->data[1] = msg[0].addr;
@@ -712,6 +753,19 @@ static int su3000_i2c_transfer(struct i2
break;
case 2:
/* always i2c read */
+ if (4 + msg[0].len > sizeof(state->data)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[0].len);
+ num = -EOPNOTSUPP;
+ break;
+ }
+ if (1 + msg[1].len > sizeof(state->data)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[1].len);
+ num = -EOPNOTSUPP;
+ break;
+ }
+
state->data[0] = 0x09;
state->data[1] = msg[0].len;
state->data[2] = msg[1].len;
Patches currently in stable-queue which might be from amilburn@zall.org are
queue-4.9/digitv-limit-messages-to-buffer-size.patch
queue-4.9/ttusb2-limit-messages-to-buffer-size.patch
queue-4.9/zr364xx-enforce-minimum-size-when-reading-header.patch
queue-4.9/dw2102-limit-messages-to-buffer-size.patch
^ permalink raw reply
* Patch "[media] gspca: konica: add missing endpoint sanity check" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: johan, gregkh, hansverk, hdegoede, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] gspca: konica: add missing endpoint sanity check
to the 4.9-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:
gspca-konica-add-missing-endpoint-sanity-check.patch
and it can be found in the queue-4.9 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 aa58fedb8c7b6cf2f05941d238495f9e2f29655c Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Mon, 13 Mar 2017 09:53:59 -0300
Subject: [media] gspca: konica: add missing endpoint sanity check
From: Johan Hovold <johan@kernel.org>
commit aa58fedb8c7b6cf2f05941d238495f9e2f29655c upstream.
Make sure to check the number of endpoints to avoid accessing memory
beyond the endpoint array should a device lack the expected endpoints.
Note that, as far as I can tell, the gspca framework has already made
sure there is at least one endpoint in the current alternate setting so
there should be no risk for a NULL-pointer dereference here.
Fixes: b517af722860 ("V4L/DVB: gspca_konica: New gspca subdriver for
konica chipset using cams")
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/gspca/konica.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/usb/gspca/konica.c
+++ b/drivers/media/usb/gspca/konica.c
@@ -188,6 +188,9 @@ static int sd_start(struct gspca_dev *gs
return -EIO;
}
+ if (alt->desc.bNumEndpoints < 2)
+ return -ENODEV;
+
packet_size = le16_to_cpu(alt->endpoint[0].desc.wMaxPacketSize);
n = gspca_dev->cam.cam_mode[gspca_dev->curr_mode].priv;
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.9/cx231xx-audio-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-io_ti-fix-div-by-zero-in-set_termios.patch
queue-4.9/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.9/usb-hub-fix-non-ss-hub-descriptor-handling.patch
queue-4.9/cx231xx-cards-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.9/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.9/usb-iowarrior-fix-info-ioctl-on-big-endian-hosts.patch
queue-4.9/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.9/gspca-konica-add-missing-endpoint-sanity-check.patch
queue-4.9/usb-serial-qcserial-add-more-lenovo-em74xx-device-ids.patch
queue-4.9/usb-serial-option-add-telit-me910-support.patch
queue-4.9/net-irda-irda-usb-fix-firmware-name-on-big-endian-hosts.patch
queue-4.9/dib0700-fix-null-deref-at-probe.patch
queue-4.9/cx231xx-audio-fix-init-error-path.patch
queue-4.9/of-fdt-add-missing-allocation-failure-check.patch
queue-4.9/usbvision-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-mct_u232-fix-big-endian-baud-rate-handling.patch
queue-4.9/mceusb-fix-null-deref-at-probe.patch
queue-4.9/usb-hub-fix-ss-hub-descriptor-handling.patch
queue-4.9/ath9k_htc-fix-null-deref-at-probe.patch
queue-4.9/usb-musb-fix-trying-to-suspend-while-active-for-otg-configurations.patch
^ permalink raw reply
* Patch "[media] digitv: limit messages to buffer size" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: amilburn, gregkh, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] digitv: limit messages to buffer size
to the 4.9-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:
digitv-limit-messages-to-buffer-size.patch
and it can be found in the queue-4.9 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 821117dc21083a99dd99174c10848d70ff43de29 Mon Sep 17 00:00:00 2001
From: Alyssa Milburn <amilburn@zall.org>
Date: Sat, 1 Apr 2017 14:33:42 -0300
Subject: [media] digitv: limit messages to buffer size
From: Alyssa Milburn <amilburn@zall.org>
commit 821117dc21083a99dd99174c10848d70ff43de29 upstream.
Return an error rather than memcpy()ing beyond the end of the buffer.
Internal callers use appropriate sizes, but digitv_i2c_xfer may not.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb/digitv.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/usb/dvb-usb/digitv.c
+++ b/drivers/media/usb/dvb-usb/digitv.c
@@ -33,6 +33,9 @@ static int digitv_ctrl_msg(struct dvb_us
wo = (rbuf == NULL || rlen == 0); /* write-only */
+ if (wlen > 4 || rlen > 4)
+ return -EIO;
+
memset(st->sndbuf, 0, 7);
memset(st->rcvbuf, 0, 7);
Patches currently in stable-queue which might be from amilburn@zall.org are
queue-4.9/digitv-limit-messages-to-buffer-size.patch
queue-4.9/ttusb2-limit-messages-to-buffer-size.patch
queue-4.9/zr364xx-enforce-minimum-size-when-reading-header.patch
queue-4.9/dw2102-limit-messages-to-buffer-size.patch
^ permalink raw reply
* Patch "[media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: d.scheller, aospan, gregkh, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops
to the 4.9-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:
dvb-frontends-cxd2841er-define-symbol_rate_min-max-in-t-c-fe-ops.patch
and it can be found in the queue-4.9 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 158f0328af86a99d64073851967a02694bff987d Mon Sep 17 00:00:00 2001
From: Daniel Scheller <d.scheller@gmx.net>
Date: Sun, 19 Mar 2017 12:26:39 -0300
Subject: [media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops
From: Daniel Scheller <d.scheller@gmx.net>
commit 158f0328af86a99d64073851967a02694bff987d upstream.
Fixes "w_scan -f c" complaining with
This dvb driver is *buggy*: the symbol rate limits are undefined - please
report to linuxtv.org)
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Acked-by: Abylay Ospan <aospan@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/dvb-frontends/cxd2841er.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -3852,7 +3852,9 @@ static struct dvb_frontend_ops cxd2841e
FE_CAN_MUTE_TS |
FE_CAN_2G_MODULATION,
.frequency_min = 42000000,
- .frequency_max = 1002000000
+ .frequency_max = 1002000000,
+ .symbol_rate_min = 870000,
+ .symbol_rate_max = 11700000
},
.init = cxd2841er_init_tc,
.sleep = cxd2841er_sleep_tc,
Patches currently in stable-queue which might be from d.scheller@gmx.net are
queue-4.9/dvb-frontends-cxd2841er-define-symbol_rate_min-max-in-t-c-fe-ops.patch
^ permalink raw reply
* Patch "[media] dib0700: fix NULL-deref at probe" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: johan, gregkh, hans.verkuil, mchehab, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] dib0700: fix NULL-deref at probe
to the 4.9-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:
dib0700-fix-null-deref-at-probe.patch
and it can be found in the queue-4.9 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 d5823511c0f8719a39e72ede1bce65411ac653b7 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Mon, 13 Mar 2017 09:53:54 -0300
Subject: [media] dib0700: fix NULL-deref at probe
From: Johan Hovold <johan@kernel.org>
commit d5823511c0f8719a39e72ede1bce65411ac653b7 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.
Fixes: c4018fa2e4c0 ("[media] dib0700: fix RC support on Hauppauge
Nova-TD")
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb/dib0700_core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -812,6 +812,9 @@ int dib0700_rc_setup(struct dvb_usb_devi
/* Starting in firmware 1.20, the RC info is provided on a bulk pipe */
+ if (intf->altsetting[0].desc.bNumEndpoints < rc_ep + 1)
+ return -ENODEV;
+
purb = usb_alloc_urb(0, GFP_KERNEL);
if (purb == NULL)
return -ENOMEM;
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.9/cx231xx-audio-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-io_ti-fix-div-by-zero-in-set_termios.patch
queue-4.9/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.9/usb-hub-fix-non-ss-hub-descriptor-handling.patch
queue-4.9/cx231xx-cards-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.9/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.9/usb-iowarrior-fix-info-ioctl-on-big-endian-hosts.patch
queue-4.9/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.9/gspca-konica-add-missing-endpoint-sanity-check.patch
queue-4.9/usb-serial-qcserial-add-more-lenovo-em74xx-device-ids.patch
queue-4.9/usb-serial-option-add-telit-me910-support.patch
queue-4.9/net-irda-irda-usb-fix-firmware-name-on-big-endian-hosts.patch
queue-4.9/dib0700-fix-null-deref-at-probe.patch
queue-4.9/cx231xx-audio-fix-init-error-path.patch
queue-4.9/of-fdt-add-missing-allocation-failure-check.patch
queue-4.9/usbvision-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-mct_u232-fix-big-endian-baud-rate-handling.patch
queue-4.9/mceusb-fix-null-deref-at-probe.patch
queue-4.9/usb-hub-fix-ss-hub-descriptor-handling.patch
queue-4.9/ath9k_htc-fix-null-deref-at-probe.patch
queue-4.9/usb-musb-fix-trying-to-suspend-while-active-for-otg-configurations.patch
^ permalink raw reply
* Patch "[media] cx231xx-audio: fix NULL-deref at probe" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: johan, Srinivasa.Deevi, gregkh, hans.verkuil, mchehab
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] cx231xx-audio: fix NULL-deref at probe
to the 4.9-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:
cx231xx-audio-fix-null-deref-at-probe.patch
and it can be found in the queue-4.9 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 65f921647f4c89a2068478c89691f39b309b58f7 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Mon, 13 Mar 2017 09:53:58 -0300
Subject: [media] cx231xx-audio: fix NULL-deref at probe
From: Johan Hovold <johan@kernel.org>
commit 65f921647f4c89a2068478c89691f39b309b58f7 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/cx231xx/cx231xx-audio.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/cx231xx/cx231xx-audio.c
+++ b/drivers/media/usb/cx231xx/cx231xx-audio.c
@@ -701,6 +701,11 @@ static int cx231xx_audio_init(struct cx2
hs_config_info[0].interface_info.
audio_index + 1];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1) {
+ err = -ENODEV;
+ goto err_free_card;
+ }
+
adev->end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].desc.
bEndpointAddress;
@@ -716,8 +721,14 @@ static int cx231xx_audio_init(struct cx2
}
for (i = 0; i < adev->num_alt; i++) {
- u16 tmp =
- le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1) {
+ err = -ENODEV;
+ goto err_free_pkt_size;
+ }
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.
wMaxPacketSize);
adev->alt_max_pkt_size[i] =
(tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
@@ -728,6 +739,8 @@ static int cx231xx_audio_init(struct cx2
return 0;
+err_free_pkt_size:
+ kfree(adev->alt_max_pkt_size);
err_free_card:
snd_card_free(card);
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.9/cx231xx-audio-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-io_ti-fix-div-by-zero-in-set_termios.patch
queue-4.9/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.9/usb-hub-fix-non-ss-hub-descriptor-handling.patch
queue-4.9/cx231xx-cards-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.9/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.9/usb-iowarrior-fix-info-ioctl-on-big-endian-hosts.patch
queue-4.9/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.9/gspca-konica-add-missing-endpoint-sanity-check.patch
queue-4.9/usb-serial-qcserial-add-more-lenovo-em74xx-device-ids.patch
queue-4.9/usb-serial-option-add-telit-me910-support.patch
queue-4.9/net-irda-irda-usb-fix-firmware-name-on-big-endian-hosts.patch
queue-4.9/dib0700-fix-null-deref-at-probe.patch
queue-4.9/cx231xx-audio-fix-init-error-path.patch
queue-4.9/of-fdt-add-missing-allocation-failure-check.patch
queue-4.9/usbvision-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-mct_u232-fix-big-endian-baud-rate-handling.patch
queue-4.9/mceusb-fix-null-deref-at-probe.patch
queue-4.9/usb-hub-fix-ss-hub-descriptor-handling.patch
queue-4.9/ath9k_htc-fix-null-deref-at-probe.patch
queue-4.9/usb-musb-fix-trying-to-suspend-while-active-for-otg-configurations.patch
^ permalink raw reply
* Patch "[media] cx231xx-cards: fix NULL-deref at probe" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: johan, Srinivasa.Deevi, gregkh, hans.verkuil, mchehab
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] cx231xx-cards: fix NULL-deref at probe
to the 4.9-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:
cx231xx-cards-fix-null-deref-at-probe.patch
and it can be found in the queue-4.9 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 0cd273bb5e4d1828efaaa8dfd11b7928131ed149 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Mon, 13 Mar 2017 09:53:56 -0300
Subject: [media] cx231xx-cards: fix NULL-deref at probe
From: Johan Hovold <johan@kernel.org>
commit 0cd273bb5e4d1828efaaa8dfd11b7928131ed149 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 45 ++++++++++++++++++++++++++----
1 file changed, 40 insertions(+), 5 deletions(-)
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1397,6 +1397,9 @@ static int cx231xx_init_v4l2(struct cx23
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
dev->video_mode.end_point_addr = uif->altsetting[0].endpoint[isoc_pipe].desc.bEndpointAddress;
dev->video_mode.num_alt = uif->num_altsetting;
@@ -1410,7 +1413,12 @@ static int cx231xx_init_v4l2(struct cx23
return -ENOMEM;
for (i = 0; i < dev->video_mode.num_alt; i++) {
- u16 tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.wMaxPacketSize);
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.wMaxPacketSize);
dev->video_mode.alt_max_pkt_size[i] = (tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
dev_dbg(dev->dev,
"Alternate setting %i, max size= %i\n", i,
@@ -1427,6 +1435,9 @@ static int cx231xx_init_v4l2(struct cx23
}
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
dev->vbi_mode.end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].desc.
bEndpointAddress;
@@ -1443,8 +1454,12 @@ static int cx231xx_init_v4l2(struct cx23
return -ENOMEM;
for (i = 0; i < dev->vbi_mode.num_alt; i++) {
- u16 tmp =
- le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
desc.wMaxPacketSize);
dev->vbi_mode.alt_max_pkt_size[i] =
(tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
@@ -1464,6 +1479,9 @@ static int cx231xx_init_v4l2(struct cx23
}
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
dev->sliced_cc_mode.end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].desc.
bEndpointAddress;
@@ -1478,7 +1496,12 @@ static int cx231xx_init_v4l2(struct cx23
return -ENOMEM;
for (i = 0; i < dev->sliced_cc_mode.num_alt; i++) {
- u16 tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
desc.wMaxPacketSize);
dev->sliced_cc_mode.alt_max_pkt_size[i] =
(tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
@@ -1647,6 +1670,11 @@ static int cx231xx_usb_probe(struct usb_
}
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1) {
+ retval = -ENODEV;
+ goto err_video_alt;
+ }
+
dev->ts1_mode.end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].
desc.bEndpointAddress;
@@ -1664,7 +1692,14 @@ static int cx231xx_usb_probe(struct usb_
}
for (i = 0; i < dev->ts1_mode.num_alt; i++) {
- u16 tmp = le16_to_cpu(uif->altsetting[i].
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1) {
+ retval = -ENODEV;
+ goto err_video_alt;
+ }
+
+ tmp = le16_to_cpu(uif->altsetting[i].
endpoint[isoc_pipe].desc.
wMaxPacketSize);
dev->ts1_mode.alt_max_pkt_size[i] =
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.9/cx231xx-audio-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-io_ti-fix-div-by-zero-in-set_termios.patch
queue-4.9/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.9/usb-hub-fix-non-ss-hub-descriptor-handling.patch
queue-4.9/cx231xx-cards-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.9/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.9/usb-iowarrior-fix-info-ioctl-on-big-endian-hosts.patch
queue-4.9/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.9/gspca-konica-add-missing-endpoint-sanity-check.patch
queue-4.9/usb-serial-qcserial-add-more-lenovo-em74xx-device-ids.patch
queue-4.9/usb-serial-option-add-telit-me910-support.patch
queue-4.9/net-irda-irda-usb-fix-firmware-name-on-big-endian-hosts.patch
queue-4.9/dib0700-fix-null-deref-at-probe.patch
queue-4.9/cx231xx-audio-fix-init-error-path.patch
queue-4.9/of-fdt-add-missing-allocation-failure-check.patch
queue-4.9/usbvision-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-mct_u232-fix-big-endian-baud-rate-handling.patch
queue-4.9/mceusb-fix-null-deref-at-probe.patch
queue-4.9/usb-hub-fix-ss-hub-descriptor-handling.patch
queue-4.9/ath9k_htc-fix-null-deref-at-probe.patch
queue-4.9/usb-musb-fix-trying-to-suspend-while-active-for-otg-configurations.patch
^ permalink raw reply
* Patch "[media] cx231xx-audio: fix init error path" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: johan, Srinivasa.Deevi, gregkh, hans.verkuil, mchehab
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] cx231xx-audio: fix init error path
to the 4.9-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:
cx231xx-audio-fix-init-error-path.patch
and it can be found in the queue-4.9 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 fff1abc4d54e469140a699612b4db8d6397bfcba Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Mon, 13 Mar 2017 09:53:57 -0300
Subject: [media] cx231xx-audio: fix init error path
From: Johan Hovold <johan@kernel.org>
commit fff1abc4d54e469140a699612b4db8d6397bfcba upstream.
Make sure to release the snd_card also on a late allocation error.
Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/cx231xx/cx231xx-audio.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
--- a/drivers/media/usb/cx231xx/cx231xx-audio.c
+++ b/drivers/media/usb/cx231xx/cx231xx-audio.c
@@ -674,10 +674,8 @@ static int cx231xx_audio_init(struct cx2
spin_lock_init(&adev->slock);
err = snd_pcm_new(card, "Cx231xx Audio", 0, 0, 1, &pcm);
- if (err < 0) {
- snd_card_free(card);
- return err;
- }
+ if (err < 0)
+ goto err_free_card;
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE,
&snd_cx231xx_pcm_capture);
@@ -691,10 +689,9 @@ static int cx231xx_audio_init(struct cx2
INIT_WORK(&dev->wq_trigger, audio_trigger);
err = snd_card_register(card);
- if (err < 0) {
- snd_card_free(card);
- return err;
- }
+ if (err < 0)
+ goto err_free_card;
+
adev->sndcard = card;
adev->udev = dev->udev;
@@ -713,9 +710,10 @@ static int cx231xx_audio_init(struct cx2
"audio EndPoint Addr 0x%x, Alternate settings: %i\n",
adev->end_point_addr, adev->num_alt);
adev->alt_max_pkt_size = kmalloc(32 * adev->num_alt, GFP_KERNEL);
-
- if (adev->alt_max_pkt_size == NULL)
- return -ENOMEM;
+ if (!adev->alt_max_pkt_size) {
+ err = -ENOMEM;
+ goto err_free_card;
+ }
for (i = 0; i < adev->num_alt; i++) {
u16 tmp =
@@ -729,6 +727,11 @@ static int cx231xx_audio_init(struct cx2
}
return 0;
+
+err_free_card:
+ snd_card_free(card);
+
+ return err;
}
static int cx231xx_audio_fini(struct cx231xx *dev)
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.9/cx231xx-audio-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-io_ti-fix-div-by-zero-in-set_termios.patch
queue-4.9/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.9/usb-hub-fix-non-ss-hub-descriptor-handling.patch
queue-4.9/cx231xx-cards-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.9/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.9/usb-iowarrior-fix-info-ioctl-on-big-endian-hosts.patch
queue-4.9/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.9/gspca-konica-add-missing-endpoint-sanity-check.patch
queue-4.9/usb-serial-qcserial-add-more-lenovo-em74xx-device-ids.patch
queue-4.9/usb-serial-option-add-telit-me910-support.patch
queue-4.9/net-irda-irda-usb-fix-firmware-name-on-big-endian-hosts.patch
queue-4.9/dib0700-fix-null-deref-at-probe.patch
queue-4.9/cx231xx-audio-fix-init-error-path.patch
queue-4.9/of-fdt-add-missing-allocation-failure-check.patch
queue-4.9/usbvision-fix-null-deref-at-probe.patch
queue-4.9/usb-serial-mct_u232-fix-big-endian-baud-rate-handling.patch
queue-4.9/mceusb-fix-null-deref-at-probe.patch
queue-4.9/usb-hub-fix-ss-hub-descriptor-handling.patch
queue-4.9/ath9k_htc-fix-null-deref-at-probe.patch
queue-4.9/usb-musb-fix-trying-to-suspend-while-active-for-otg-configurations.patch
^ permalink raw reply
* Patch "ipx: call ipxitf_put() in ioctl error path" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 13:41 UTC (permalink / raw)
To: dan.carpenter, davem, gregkh, liqiang6-s; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ipx: call ipxitf_put() in ioctl error path
to the 4.4-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:
ipx-call-ipxitf_put-in-ioctl-error-path.patch
and it can be found in the queue-4.4 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 ee0d8d8482345ff97a75a7d747efc309f13b0d80 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 2 May 2017 13:58:53 +0300
Subject: ipx: call ipxitf_put() in ioctl error path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dan Carpenter <dan.carpenter@oracle.com>
commit ee0d8d8482345ff97a75a7d747efc309f13b0d80 upstream.
We should call ipxitf_put() if the copy_to_user() fails.
Reported-by: 李强 <liqiang6-s@360.cn>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipx/af_ipx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1168,11 +1168,10 @@ static int ipxitf_ioctl(unsigned int cmd
sipx->sipx_network = ipxif->if_netnum;
memcpy(sipx->sipx_node, ipxif->if_node,
sizeof(sipx->sipx_node));
- rc = -EFAULT;
+ rc = 0;
if (copy_to_user(arg, &ifr, sizeof(ifr)))
- break;
+ rc = -EFAULT;
ipxitf_put(ipxif);
- rc = 0;
break;
}
case SIOCAIPXITFCRT:
Patches currently in stable-queue which might be from dan.carpenter@oracle.com are
queue-4.4/ext4-crypto-fix-some-error-handling.patch
queue-4.4/ipx-call-ipxitf_put-in-ioctl-error-path.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