Hi Greg / stable maintainer(s),
IIUC, this commit is a good candidate for -stable. I just hit the bug on
4.14, because of new vendor firmware that noticed the mismatched length
(an internal "assert"), but it seems like this is equally problematic
from the kernel side for as long as this code existed [1]:
commit c8291988806407e02a01b4b15b4504eafbcc04e0
Author: Zhi Chen <zhichen(a)codeaurora.org>
Date: Mon Jun 18 17:00:39 2018 +0300
ath10k: fix scan crash due to incorrect length calculation
Thanks,
Brian
[1] I guess that would be:
Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
which was in v4.0.
Hi Greg,
This was not marked for stable but seems it should be in stable.
Please apply to your queue of 4.14-stable.
And at the same time, there was another later patch which fixed a bug
in this patch. Both are attached as a series to this mail.
--
Regards
Sudip
There are five patches to fix CVE-2018-5390 in latest mainline
branch, but only two patches exist in stable 4.4 and 3.18:
dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
I have tested with stable 4.4 kernel, and found the cpu usage was very high.
So I think only two patches can't fix the CVE-2018-5390.
test results:
with fix patch: 78.2% ksoftirqd
withoutfix patch: 90% ksoftirqd
Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue
instead of RB tree. The result is not very well.
After analysing the codes of stable 4.4, and debuging the
system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
Stable 4.4 have already back port two patches,
f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
If we want to change simple queue to RB tree to finally resolve, we should apply previous
patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many
conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in
mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly,
then apply 9f5afeae, and reapply five patches from Eric.
V1->V2:
1) Don't revert 3d4bf93a and f4a3313d firstly, all of 6 patches based on 4.4.155.
2) Add one bug fix patch for RB tree:76f0dcbb5ae1a7c3dbeec13dd98233b8e6b0b32a tcp: fix a stale ooo_last_skb
Eric Dumazet (5):
tcp: increment sk_drops for dropped rx packets
tcp: fix a stale ooo_last_skb after a replace
tcp: free batches of packets in tcp_prune_ofo_queue()
tcp: call tcp_drop() from tcp_data_queue_ofo()
tcp: add tcp_ooo_try_coalesce() helper
Yaogong Wang (1):
tcp: use an RB tree for ooo receive queue
include/linux/skbuff.h | 8 +
include/linux/tcp.h | 7 +-
include/net/sock.h | 7 +
include/net/tcp.h | 2 +-
net/core/skbuff.c | 19 +++
net/ipv4/tcp.c | 4 +-
net/ipv4/tcp_input.c | 417 +++++++++++++++++++++++++++++------------------
net/ipv4/tcp_ipv4.c | 3 +-
net/ipv4/tcp_minisocks.c | 1 -
net/ipv6/tcp_ipv6.c | 1 +
10 files changed, 297 insertions(+), 172 deletions(-)
--
1.8.3.1
Hi Greg,
The problem had been fixed by 764a5c6b1fa4 ("xattr handlers: Simplify list
operation") in v4.5-rc1, but the modification in that commit may be too much
because it modifies all file-systems which implement xattr, so I create a single
patch for jffs2 to fix the problem. Which one is your preference ?
Hi Andreas,
Could you please help review the patch ?
Thanks,
Tao
---
From: Hou Tao <houtao1(a)huawei.com>
When a file have multiple xattrs and the passed buffer is
smaller than the required size, jffs2_listxattr() should
return -ERANGE instead of continue, else Oops may occurs
due to memory corruption.
Also remove the unnecessary check ("rc < 0"), because
xhandle->list(...) will not return an error number.
Spotted by generic/377 in xfstests-dev.
Signed-off-by: Hou Tao <houtao1(a)huawei.com>
---
fs/jffs2/xattr.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c
index 4c2c03663533..8e1427762eeb 100644
--- a/fs/jffs2/xattr.c
+++ b/fs/jffs2/xattr.c
@@ -1004,12 +1004,14 @@ ssize_t jffs2_listxattr(struct dentry *dentry, char *buffer, size_t size)
rc = xhandle->list(xhandle, dentry, buffer + len,
size - len, xd->xname,
xd->name_len);
+ if (rc > size - len) {
+ rc = -ERANGE;
+ goto out;
+ }
} else {
rc = xhandle->list(xhandle, dentry, NULL, 0,
xd->xname, xd->name_len);
}
- if (rc < 0)
- goto out;
len += rc;
}
rc = len;
--
The DTK-2451 and DTH-2452 have a buggy HID descriptor which incorrectly
contains a Cintiq-like report, complete with pen tilt, rotation, twist,
serial number, etc. The hardware doesn't actually support this data but
our driver duitifully sets up the device as though it does. To ensure
userspace has a correct view of devices without updated firmware, we clean
up this incorrect data in wacom_setup_device_quirks.
We're also careful to clear the WACOM_QUIRK_TOOLSERIAL flag since its
presence causes the driver to wait for serial number information (via
wacom_wac_pen_serial_enforce) that never comes, resulting in the pen
being non-responsive.
Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
Fixes: 8341720642 ("HID: wacom: Queue events with missing type/serial data for later processing")
Cc: stable(a)vger.kernel.org # v4.16+
---
drivers/hid/wacom_wac.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index e0a06be5ef5c..b4b4a30e3982 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3335,6 +3335,7 @@ static void wacom_setup_intuos(struct wacom_wac *wacom_wac)
void wacom_setup_device_quirks(struct wacom *wacom)
{
+ struct wacom_wac *wacom_wac = &wacom->wacom_wac;
struct wacom_features *features = &wacom->wacom_wac.features;
/* The pen and pad share the same interface on most devices */
@@ -3464,6 +3465,25 @@ void wacom_setup_device_quirks(struct wacom *wacom)
if (features->type == REMOTE)
features->device_type |= WACOM_DEVICETYPE_WL_MONITOR;
+
+ /* HID descriptor for DTK-2451 / DTH-2452 claims to report lots
+ * of things it shouldn't. Lets fix up the damage...
+ */
+ if (wacom->hdev->product == 0x382 || wacom->hdev->product == 0x37d) {
+ features->quirks &= ~WACOM_QUIRK_TOOLSERIAL;
+ __clear_bit(BTN_TOOL_BRUSH, wacom_wac->pen_input->keybit);
+ __clear_bit(BTN_TOOL_PENCIL, wacom_wac->pen_input->keybit);
+ __clear_bit(BTN_TOOL_AIRBRUSH, wacom_wac->pen_input->keybit);
+ __clear_bit(ABS_Z, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_DISTANCE, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_TILT_X, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_TILT_Y, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_WHEEL, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_MISC, wacom_wac->pen_input->absbit);
+ __clear_bit(MSC_SERIAL, wacom_wac->pen_input->mscbit);
+ __clear_bit(EV_MSC, wacom_wac->pen_input->evbit);
+ }
}
int wacom_setup_pen_input_capabilities(struct input_dev *input_dev,
--
2.19.1
Hi Greg,
The backport of upstream commit 1bd6a1c4b80a ("powerpc/fadump: handle
crash memory ranges array index overflow") introduced a ppc build failure
on 4.4-stable and 4.9-stable when CONFIG_FA_DUMP is enabled:
arch/powerpc/kernel/fadump.c: In function ‘register_fadump’:
arch/powerpc/kernel/fadump.c:1015:10: error: ‘return’ with a value, in function returning void [-Werror]
return ret;
^~~
arch/powerpc/kernel/fadump.c:1000:13: note: declared here
static void register_fadump(void)
^~~~~~~~~~~~~~~
I am suggesting to fix it by backporting 98b8cd7f7564 ("powerpc/fadump:
Return error when fadump registration fails"), which is an earlier
commit that (among other things) set the return of register_fadump() to
int and has little functional changes. It was applied upstream for
v4.13, so 4.14-stable and later are already fixed.
Thanks,
Kleber
Michal Suchanek (1):
powerpc/fadump: Return error when fadump registration fails
arch/powerpc/kernel/fadump.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
--
2.17.1
The patch below does not apply to the 4.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(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From b45ba4a51cde29b2939365ef0c07ad34c8321789 Mon Sep 17 00:00:00 2001
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Mon, 1 Oct 2018 12:21:10 +0000
Subject: [PATCH] powerpc/lib: fix book3s/32 boot failure due to code patching
Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init
sections") accesses 'init_mem_is_free' flag too early, before the
kernel is relocated. This provokes early boot failure (before the
console is active).
As it is not necessary to do this verification that early, this
patch moves the test into patch_instruction() instead of
__patch_instruction().
This modification also has the advantage of avoiding unnecessary
remappings.
Fixes: 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections")
Cc: stable(a)vger.kernel.org # 4.13+
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 6ae2777c220d..5ffee298745f 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -28,12 +28,6 @@ static int __patch_instruction(unsigned int *exec_addr, unsigned int instr,
{
int err;
- /* Make sure we aren't patching a freed init section */
- if (init_mem_is_free && init_section_contains(exec_addr, 4)) {
- pr_debug("Skipping init section patching addr: 0x%px\n", exec_addr);
- return 0;
- }
-
__put_user_size(instr, patch_addr, 4, err);
if (err)
return err;
@@ -148,7 +142,7 @@ static inline int unmap_patch_area(unsigned long addr)
return 0;
}
-int patch_instruction(unsigned int *addr, unsigned int instr)
+static int do_patch_instruction(unsigned int *addr, unsigned int instr)
{
int err;
unsigned int *patch_addr = NULL;
@@ -188,12 +182,22 @@ int patch_instruction(unsigned int *addr, unsigned int instr)
}
#else /* !CONFIG_STRICT_KERNEL_RWX */
-int patch_instruction(unsigned int *addr, unsigned int instr)
+static int do_patch_instruction(unsigned int *addr, unsigned int instr)
{
return raw_patch_instruction(addr, instr);
}
#endif /* CONFIG_STRICT_KERNEL_RWX */
+
+int patch_instruction(unsigned int *addr, unsigned int instr)
+{
+ /* Make sure we aren't patching a freed init section */
+ if (init_mem_is_free && init_section_contains(addr, 4)) {
+ pr_debug("Skipping init section patching addr: 0x%px\n", addr);
+ return 0;
+ }
+ return do_patch_instruction(addr, instr);
+}
NOKPROBE_SYMBOL(patch_instruction);
int patch_branch(unsigned int *addr, unsigned long target, int flags)