* [PATCH 3.18 01/13] netfilter: drop outermost socket lock in getsockopt()
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 02/13] PCI: keystone: Fix interrupt-controller-node lookup Greg Kroah-Hartman
` (15 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Xin Long,
syzbot+ddde1c7b7ff7442d7f2d, Florian Westphal, Paolo Abeni,
Pablo Neira Ayuso, Krzysztof Piotr Oledzki
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <pabeni@redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin@gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1375,10 +1375,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1410,9 +1407,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1314,10 +1314,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1356,10 +1353,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 02/13] PCI: keystone: Fix interrupt-controller-node lookup
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 01/13] netfilter: drop outermost socket lock in getsockopt() Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 03/13] xtensa: fix high memory/reserved memory collision Greg Kroah-Hartman
` (14 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Murali Karicheri, Johan Hovold,
Lorenzo Pieralisi
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable@vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
[lorenzo.pieralisi@arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
[johan: backport to 4.4]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/host/pci-keystone.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -179,14 +179,16 @@ static int ks_pcie_get_irq_controller_in
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
goto out;
}
temp = of_irq_count(*np_temp);
- if (!temp)
+ if (!temp) {
+ of_node_put(*np_temp);
goto out;
+ }
if (temp > max_host_irqs)
dev_warn(dev, "Too many %s interrupts defined %u\n",
(legacy ? "legacy" : "MSI"), temp);
@@ -200,6 +202,9 @@ static int ks_pcie_get_irq_controller_in
if (host_irqs[temp] < 0)
break;
}
+
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
ret = 0;
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 03/13] xtensa: fix high memory/reserved memory collision
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 01/13] netfilter: drop outermost socket lock in getsockopt() Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 02/13] PCI: keystone: Fix interrupt-controller-node lookup Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 04/13] scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info Greg Kroah-Hartman
` (13 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Max Filippov
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <jcmvbkbc@gmail.com>
commit 6ac5a11dc674bc5016ea716e8082fff61f524dc1 upstream.
Xtensa memory initialization code frees high memory pages without
checking whether they are in the reserved memory regions or not. That
results in invalid value of totalram_pages and duplicate page usage by
CMA and highmem. It produces a bunch of BUGs at startup looking like
this:
BUG: Bad page state in process swapper pfn:70800
page:be60c000 count:0 mapcount:-127 mapping: (null) index:0x1
flags: 0x80000000()
raw: 80000000 00000000 00000001 ffffff80 00000000 be60c014 be60c014 0000000a
page dumped because: nonzero mapcount
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Tainted: G B 4.16.0-rc1-00015-g7928b2cbe55b-dirty #23
Stack:
bd839d33 00000000 00000018 ba97b64c a106578c bd839d70 be60c000 00000000
a1378054 bd86a000 00000003 ba97b64c a1066166 bd839da0 be60c000 ffe00000
a1066b58 bd839dc0 be504000 00000000 000002f4 bd838000 00000000 0000001e
Call Trace:
[<a1065734>] bad_page+0xac/0xd0
[<a106578c>] free_pages_check_bad+0x34/0x4c
[<a1066166>] __free_pages_ok+0xae/0x14c
[<a1066b58>] __free_pages+0x30/0x64
[<a1365de5>] init_cma_reserved_pageblock+0x35/0x44
[<a13682dc>] cma_init_reserved_areas+0xf4/0x148
[<a10034b8>] do_one_initcall+0x80/0xf8
[<a1361c16>] kernel_init_freeable+0xda/0x13c
[<a125b59d>] kernel_init+0x9/0xd0
[<a1004304>] ret_from_kernel_thread+0xc/0x18
Only free high memory pages that are not reserved.
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/xtensa/mm/init.c | 70 +++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 63 insertions(+), 7 deletions(-)
--- a/arch/xtensa/mm/init.c
+++ b/arch/xtensa/mm/init.c
@@ -307,19 +307,75 @@ void __init zones_init(void)
free_area_init_node(0, zones_size, ARCH_PFN_OFFSET, NULL);
}
+#ifdef CONFIG_HIGHMEM
+static void __init free_area_high(unsigned long pfn, unsigned long end)
+{
+ for (; pfn < end; pfn++)
+ free_highmem_page(pfn_to_page(pfn));
+}
+
+static void __init free_highpages(void)
+{
+ unsigned long max_low = max_low_pfn;
+ struct memblock_region *mem, *res;
+
+ reset_all_zones_managed_pages();
+ /* set highmem page free */
+ for_each_memblock(memory, mem) {
+ unsigned long start = memblock_region_memory_base_pfn(mem);
+ unsigned long end = memblock_region_memory_end_pfn(mem);
+
+ /* Ignore complete lowmem entries */
+ if (end <= max_low)
+ continue;
+
+ if (memblock_is_nomap(mem))
+ continue;
+
+ /* Truncate partial highmem entries */
+ if (start < max_low)
+ start = max_low;
+
+ /* Find and exclude any reserved regions */
+ for_each_memblock(reserved, res) {
+ unsigned long res_start, res_end;
+
+ res_start = memblock_region_reserved_base_pfn(res);
+ res_end = memblock_region_reserved_end_pfn(res);
+
+ if (res_end < start)
+ continue;
+ if (res_start < start)
+ res_start = start;
+ if (res_start > end)
+ res_start = end;
+ if (res_end > end)
+ res_end = end;
+ if (res_start != start)
+ free_area_high(start, res_start);
+ start = res_end;
+ if (start == end)
+ break;
+ }
+
+ /* And now free anything which remains */
+ if (start < end)
+ free_area_high(start, end);
+ }
+}
+#else
+static void __init free_highpages(void)
+{
+}
+#endif
+
/*
* Initialize memory pages.
*/
void __init mem_init(void)
{
-#ifdef CONFIG_HIGHMEM
- unsigned long tmp;
-
- reset_all_zones_managed_pages();
- for (tmp = max_low_pfn; tmp < max_pfn; tmp++)
- free_highmem_page(pfn_to_page(tmp));
-#endif
+ free_highpages();
max_mapnr = max_pfn - ARCH_PFN_OFFSET;
high_memory = (void *)__va(max_low_pfn << PAGE_SHIFT);
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 04/13] scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 03/13] xtensa: fix high memory/reserved memory collision Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 05/13] cfg80211: fix cfg80211_beacon_dup Greg Kroah-Hartman
` (12 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hannes Reinecke, Tyrel Datwyler,
Martin K. Petersen
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable@vger.kernel.org>
Reported-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -366,7 +366,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 05/13] cfg80211: fix cfg80211_beacon_dup
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 04/13] scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 06/13] iio: buffer: check if a buffer has been set up when poll is called Greg Kroah-Hartman
` (11 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Johannes Berg
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable@vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2769,7 +2769,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 06/13] iio: buffer: check if a buffer has been set up when poll is called
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 05/13] cfg80211: fix cfg80211_beacon_dup Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 07/13] iio: adis_lib: Initialize trigger before requesting interrupt Greg Kroah-Hartman
` (10 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Windfeldt-Prytz, Jonathan Cameron
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Windfeldt-Prytz <stefan.windfeldt@axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt@axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -92,7 +92,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 07/13] iio: adis_lib: Initialize trigger before requesting interrupt
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 06/13] iio: buffer: check if a buffer has been set up when poll is called Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 08/13] x86/oprofile: Fix bogus GCC-8 warning in nmi_setup() Greg Kroah-Hartman
` (9 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Robin Getz, Lars-Peter Clausen,
Stable, Jonathan Cameron
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <lars@metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz@analog.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 08/13] x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 07/13] iio: adis_lib: Initialize trigger before requesting interrupt Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 09/13] irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq() Greg Kroah-Hartman
` (8 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Jessica Yu, Kees Cook,
Linus Torvalds, Martin Sebor, Peter Zijlstra, Robert Richter,
Thomas Gleixner, oprofile-list, Ingo Molnar
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Sebor <msebor@gcc.gnu.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <rric@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: oprofile-list@lists.sf.net
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -471,7 +471,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 09/13] irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 08/13] x86/oprofile: Fix bogus GCC-8 warning in nmi_setup() Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 10/13] arm64: Disable unhandled signal log messages by default Greg Kroah-Hartman
` (7 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Shanker Donthineni, Marc Zyngier
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shanker Donthineni <shankerd@codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable@vger.kernel.org
Acked-by: Will Deacon <will.deacon@arm.com>,
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -503,7 +503,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu_mask(cpu, *mask) {
u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 10/13] arm64: Disable unhandled signal log messages by default
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 09/13] irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq() Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 11/13] usb: dwc3: gadget: Set maxpacket size for ep0 IN Greg Kroah-Hartman
` (6 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Weiser, Will Deacon
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Weiser <michael.weiser@gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable@vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -45,7 +45,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some memory nicely...
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 11/13] usb: dwc3: gadget: Set maxpacket size for ep0 IN
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 10/13] arm64: Disable unhandled signal log messages by default Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 12/13] usb: gadget: f_fs: Process all descriptors during bind Greg Kroah-Hartman
` (5 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Thinh Nguyen, Felipe Balbi
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable@vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2345,6 +2345,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A)
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 12/13] usb: gadget: f_fs: Process all descriptors during bind
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 11/13] usb: dwc3: gadget: Set maxpacket size for ep0 IN Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-26 20:15 ` [PATCH 3.18 13/13] ASN.1: fix out-of-bounds read when parsing indefinite length item Greg Kroah-Hartman
` (4 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mayank Rana, Jack Pham, Felipe Balbi
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jack Pham <jackp@codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable@vger.kernel.org
Co-Developed-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2727,10 +2727,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 3.18 13/13] ASN.1: fix out-of-bounds read when parsing indefinite length item
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 12/13] usb: gadget: f_fs: Process all descriptors during bind Greg Kroah-Hartman
@ 2018-02-26 20:15 ` Greg Kroah-Hartman
2018-02-27 0:53 ` [PATCH 3.18 00/13] 3.18.97-stable review Shuah Khan
` (3 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-26 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Potapenko, Eric Biggers,
David Howells
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit e0058f3a874ebb48b25be7ff79bc3b4e59929f90 upstream.
In asn1_ber_decoder(), indefinitely-sized ASN.1 items were being passed
to the action functions before their lengths had been computed, using
the bogus length of 0x80 (ASN1_INDEFINITE_LENGTH). This resulted in
reading data past the end of the input buffer, when given a specially
crafted message.
Fix it by rearranging the code so that the indefinite length is resolved
before the action is called.
This bug was originally found by fuzzing the X.509 parser in userspace
using libFuzzer from the LLVM project.
KASAN report (cleaned up slightly):
BUG: KASAN: slab-out-of-bounds in memcpy ./include/linux/string.h:341 [inline]
BUG: KASAN: slab-out-of-bounds in x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
Read of size 128 at addr ffff880035dd9eaf by task keyctl/195
CPU: 1 PID: 195 Comm: keyctl Not tainted 4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xd1/0x175 lib/dump_stack.c:53
print_address_description+0x78/0x260 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x23f/0x350 mm/kasan/report.c:409
memcpy+0x1f/0x50 mm/kasan/kasan.c:302
memcpy ./include/linux/string.h:341 [inline]
x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
asn1_ber_decoder+0xb4a/0x1fd0 lib/asn1_decoder.c:447
x509_cert_parse+0x1c7/0x620 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Allocated by task 195:
__do_kmalloc_node mm/slab.c:3675 [inline]
__kmalloc_node+0x47/0x60 mm/slab.c:3682
kvmalloc ./include/linux/mm.h:540 [inline]
SYSC_add_key security/keys/keyctl.c:104 [inline]
SyS_add_key+0x19e/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Reported-by: Alexander Potapenko <glider@google.com>
Cc: <stable@vger.kernel.org> # v3.7+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/asn1_decoder.c | 43 ++++++++++++++++++++++++-------------------
1 file changed, 24 insertions(+), 19 deletions(-)
--- a/lib/asn1_decoder.c
+++ b/lib/asn1_decoder.c
@@ -305,38 +305,43 @@ next_op:
/* Decide how to handle the operation */
switch (op) {
- case ASN1_OP_MATCH_ANY_ACT:
- case ASN1_OP_COND_MATCH_ANY_ACT:
- ret = actions[machine[pc + 1]](context, hdr, tag, data + dp, len);
- if (ret < 0)
- return ret;
- goto skip_data;
-
- case ASN1_OP_MATCH_ACT:
- case ASN1_OP_MATCH_ACT_OR_SKIP:
- case ASN1_OP_COND_MATCH_ACT_OR_SKIP:
- ret = actions[machine[pc + 2]](context, hdr, tag, data + dp, len);
- if (ret < 0)
- return ret;
- goto skip_data;
-
case ASN1_OP_MATCH:
case ASN1_OP_MATCH_OR_SKIP:
+ case ASN1_OP_MATCH_ACT:
+ case ASN1_OP_MATCH_ACT_OR_SKIP:
case ASN1_OP_MATCH_ANY:
+ case ASN1_OP_MATCH_ANY_ACT:
case ASN1_OP_COND_MATCH_OR_SKIP:
+ case ASN1_OP_COND_MATCH_ACT_OR_SKIP:
case ASN1_OP_COND_MATCH_ANY:
- skip_data:
+ case ASN1_OP_COND_MATCH_ANY_ACT:
+
if (!(flags & FLAG_CONS)) {
if (flags & FLAG_INDEFINITE_LENGTH) {
+ size_t tmp = dp;
+
ret = asn1_find_indefinite_length(
- data, datalen, &dp, &len, &errmsg);
+ data, datalen, &tmp, &len, &errmsg);
if (ret < 0)
goto error;
- } else {
- dp += len;
}
pr_debug("- LEAF: %zu\n", len);
}
+
+ if (op & ASN1_OP_MATCH__ACT) {
+ unsigned char act;
+
+ if (op & ASN1_OP_MATCH__ANY)
+ act = machine[pc + 1];
+ else
+ act = machine[pc + 2];
+ ret = actions[act](context, hdr, tag, data + dp, len);
+ if (ret < 0)
+ return ret;
+ }
+
+ if (!(flags & FLAG_CONS))
+ dp += len;
pc += asn1_op_lengths[op];
goto next_op;
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 3.18 00/13] 3.18.97-stable review
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2018-02-26 20:15 ` [PATCH 3.18 13/13] ASN.1: fix out-of-bounds read when parsing indefinite length item Greg Kroah-Hartman
@ 2018-02-27 0:53 ` Shuah Khan
2018-02-27 2:17 ` Harsh Shandilya
` (2 subsequent siblings)
16 siblings, 0 replies; 20+ messages in thread
From: Shuah Khan @ 2018-02-27 0:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, Shuah Khan
On 02/26/2018 01:15 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.97 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.97-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 3.18 00/13] 3.18.97-stable review
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2018-02-27 0:53 ` [PATCH 3.18 00/13] 3.18.97-stable review Shuah Khan
@ 2018-02-27 2:17 ` Harsh Shandilya
2018-02-27 13:10 ` Greg Kroah-Hartman
2018-02-27 4:58 ` kernelci.org bot
2018-02-27 14:53 ` Guenter Roeck
16 siblings, 1 reply; 20+ messages in thread
From: Harsh Shandilya @ 2018-02-27 2:17 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: akpm, ben.hutchings, linux, linux-kernel, lkft-triage, patches,
shuahkh, stable, torvalds
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
On Tue 27 Feb, 2018, 1:47 AM Greg Kroah-Hartman, <gregkh@linuxfoundation.org>
wrote:
> This is the start of the stable review cycle for the 3.18.97 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>
> https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.97-rc1.gz
> or in the git tree and branch at:
> git://
> git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-3.18.y
> and the diffstat can be found below.
>
No regressions noticed on the OnePlus 3T. CAF's msm-3.18 tree requires
reverting commit
https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit?id=1278f001ef9bf1329bc2aa123f6038ad9f8a65ee
to avoid conflicting with the patch titled "usb: gadget: f_fs: Process all
descriptors during bind", kernel-common has no merge problems. Thanks for
the update.
Harsh Shandilya
[-- Attachment #2: Type: text/html, Size: 2000 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 3.18 00/13] 3.18.97-stable review
2018-02-27 2:17 ` Harsh Shandilya
@ 2018-02-27 13:10 ` Greg Kroah-Hartman
0 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-27 13:10 UTC (permalink / raw)
To: Harsh Shandilya
Cc: akpm, ben.hutchings, linux, linux-kernel, lkft-triage, patches,
shuahkh, stable, torvalds
On Tue, Feb 27, 2018 at 02:17:15AM +0000, Harsh Shandilya wrote:
> On Tue 27 Feb, 2018, 1:47 AM Greg Kroah-Hartman, <gregkh@linuxfoundation.org>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.97 release.
> > There are 13 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.97-rc1.gz
> > or in the git tree and branch at:
> > git://
> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
>
> No regressions noticed on the OnePlus 3T. CAF's msm-3.18 tree requires
> reverting commit
> https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit?id=1278f001ef9bf1329bc2aa123f6038ad9f8a65ee
> to avoid conflicting with the patch titled "usb: gadget: f_fs: Process all
> descriptors during bind", kernel-common has no merge problems. Thanks for
> the update.
Thanks for testing this and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3.18 00/13] 3.18.97-stable review
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2018-02-27 2:17 ` Harsh Shandilya
@ 2018-02-27 4:58 ` kernelci.org bot
2018-02-27 14:53 ` Guenter Roeck
16 siblings, 0 replies; 20+ messages in thread
From: kernelci.org bot @ 2018-02-27 4:58 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
stable-rc/linux-3.18.y boot: 62 boots: 0 failed, 58 passed with 2 offline, 2 untried/unknown (v3.18.96-14-g9fdaa6623e85)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.96-14-g9fdaa6623e85/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.96-14-g9fdaa6623e85/
Tree: stable-rc
Branch: linux-3.18.y
Git Describe: v3.18.96-14-g9fdaa6623e85
Git Commit: 9fdaa6623e85034df1bae98e3a543606a0098861
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 30 unique boards, 13 SoC families, 14 builds out of 171
Offline Platforms:
arm:
multi_v7_defconfig:
exynos5410-odroidxu: 1 offline lab
exynos_defconfig:
exynos5410-odroidxu: 1 offline lab
---
For more info write to <info@kernelci.org>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 3.18 00/13] 3.18.97-stable review
2018-02-26 20:15 [PATCH 3.18 00/13] 3.18.97-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2018-02-27 4:58 ` kernelci.org bot
@ 2018-02-27 14:53 ` Guenter Roeck
2018-02-27 18:32 ` Greg Kroah-Hartman
16 siblings, 1 reply; 20+ messages in thread
From: Guenter Roeck @ 2018-02-27 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, lkft-triage, stable
On 02/26/2018 12:15 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.97 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> Anything received after that time might be too late.
>
Build results:
total: 136 pass: 135 fail: 1
Failed builds:
xtensa:allmodconfig
Qemu test results:
total: 112 pass: 108 fail: 4
Failed tests:
xtensa:dc232b:lx60:generic_kc705_defconfig
xtensa:dc232b:kc705:generic_kc705_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfig
Presumably the xtensa patch does not apply to this kernel.
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 3.18 00/13] 3.18.97-stable review
2018-02-27 14:53 ` Guenter Roeck
@ 2018-02-27 18:32 ` Greg Kroah-Hartman
0 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-27 18:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
lkft-triage, stable
On Tue, Feb 27, 2018 at 06:53:58AM -0800, Guenter Roeck wrote:
> On 02/26/2018 12:15 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.97 release.
> > There are 13 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 136 pass: 135 fail: 1
> Failed builds:
> xtensa:allmodconfig
> Qemu test results:
> total: 112 pass: 108 fail: 4
> Failed tests:
> xtensa:dc232b:lx60:generic_kc705_defconfig
> xtensa:dc232b:kc705:generic_kc705_defconfig
> xtensa:dc233c:ml605:generic_kc705_defconfig
> xtensa:dc233c:kc705:generic_kc705_defconfig
>
> Presumably the xtensa patch does not apply to this kernel.
>
> Details are available at http://kerneltests.org/builders.
xtensa patch is now dropped, thanks.
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread