Hi Sasha,
These build issues can be fixed by including linux/nospec.h to
arch/x86/kvm/mtrr.c. Below you can find a patch that compiles on both
v4.9.206 and v4.4.206.
Please let me know if you need anything else.
Marios
========
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 0149ac59c273..f223f1315998 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -18,6 +18,7 @@
#include <linux/kvm_host.h>
#include <asm/mtrr.h>
+#include <linux/nospec.h>
#include "cpuid.h"
#include "mmu.h"
@@ -202,11 +203,15 @@ static bool fixed_msr_to_seg_unit(u32 msr, int
*seg, int *unit)
break;
case MSR_MTRRfix16K_80000 ... MSR_MTRRfix16K_A0000:
*seg = 1;
- *unit = msr - MSR_MTRRfix16K_80000;
+ *unit = array_index_nospec(
+ msr - MSR_MTRRfix16K_80000,
+ MSR_MTRRfix16K_A0000 - MSR_MTRRfix16K_80000 + 1);
break;
case MSR_MTRRfix4K_C0000 ... MSR_MTRRfix4K_F8000:
*seg = 2;
- *unit = msr - MSR_MTRRfix4K_C0000;
+ *unit = array_index_nospec(
+ msr - MSR_MTRRfix4K_C0000,
+ MSR_MTRRfix4K_F8000 - MSR_MTRRfix4K_C0000 + 1);
break;
default:
return false;
On Wed, Dec 25, 2019 at 3:55 PM Sasha Levin <sashal(a)kernel.org> wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: de9aef5e1ad6 ("KVM: MTRR: introduce fixed_mtrr_segment table").
>
> The bot has tested the following trees: v5.4.5, v5.3.18, v4.19.90, v4.14.159, v4.9.206, v4.4.206.
>
> v5.4.5: Build OK!
> v5.3.18: Build OK!
> v4.19.90: Build OK!
> v4.14.159: Build OK!
> v4.9.206: Build failed! Errors:
> arch/x86/kvm/mtrr.c:205:11: error: implicit declaration of function ‘array_index_nospec’; did you mean ‘array_index_mask_nospec’? [-Werror=implicit-function-declaration]
>
> v4.4.206: Build failed! Errors:
> arch/x86/kvm/mtrr.c:205:11: error: implicit declaration of function ‘array_index_nospec’; did you mean ‘array_index_mask_nospec’? [-Werror=implicit-function-declaration]
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
--
Marios Pomonis
Software Engineer, Security
GCP Platform Security
US-KIR-6THC
This is a note to let you know that I've just added the patch titled
USB: core: fix check for duplicate endpoints
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 3e4f8e21c4f27bcf30a48486b9dcc269512b79ff Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Thu, 19 Dec 2019 17:10:16 +0100
Subject: USB: core: fix check for duplicate endpoints
Amend the endpoint-descriptor sanity checks to detect all duplicate
endpoint addresses in a configuration.
Commit 0a8fd1346254 ("USB: fix problems with duplicate endpoint
addresses") added a check for duplicate endpoint addresses within a
single alternate setting, but did not look for duplicate addresses in
other interfaces.
The current check would also not detect all duplicate addresses when one
endpoint is as a (bi-directional) control endpoint.
This specifically avoids overwriting the endpoint entries in struct
usb_device when enabling a duplicate endpoint, something which could
potentially lead to crashes or leaks, for example, when endpoints are
later disabled.
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Link: https://lore.kernel.org/r/20191219161016.6695-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/config.c | 70 ++++++++++++++++++++++++++++++++-------
1 file changed, 58 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 5f40117e68e7..21291950cc97 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -203,9 +203,58 @@ static const unsigned short super_speed_maxpacket_maxes[4] = {
[USB_ENDPOINT_XFER_INT] = 1024,
};
-static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
- int asnum, struct usb_host_interface *ifp, int num_ep,
- unsigned char *buffer, int size)
+static bool endpoint_is_duplicate(struct usb_endpoint_descriptor *e1,
+ struct usb_endpoint_descriptor *e2)
+{
+ if (e1->bEndpointAddress == e2->bEndpointAddress)
+ return true;
+
+ if (usb_endpoint_xfer_control(e1) || usb_endpoint_xfer_control(e2)) {
+ if (usb_endpoint_num(e1) == usb_endpoint_num(e2))
+ return true;
+ }
+
+ return false;
+}
+
+/*
+ * Check for duplicate endpoint addresses in other interfaces and in the
+ * altsetting currently being parsed.
+ */
+static bool config_endpoint_is_duplicate(struct usb_host_config *config,
+ int inum, int asnum, struct usb_endpoint_descriptor *d)
+{
+ struct usb_endpoint_descriptor *epd;
+ struct usb_interface_cache *intfc;
+ struct usb_host_interface *alt;
+ int i, j, k;
+
+ for (i = 0; i < config->desc.bNumInterfaces; ++i) {
+ intfc = config->intf_cache[i];
+
+ for (j = 0; j < intfc->num_altsetting; ++j) {
+ alt = &intfc->altsetting[j];
+
+ if (alt->desc.bInterfaceNumber == inum &&
+ alt->desc.bAlternateSetting != asnum)
+ continue;
+
+ for (k = 0; k < alt->desc.bNumEndpoints; ++k) {
+ epd = &alt->endpoint[k].desc;
+
+ if (endpoint_is_duplicate(epd, d))
+ return true;
+ }
+ }
+ }
+
+ return false;
+}
+
+static int usb_parse_endpoint(struct device *ddev, int cfgno,
+ struct usb_host_config *config, int inum, int asnum,
+ struct usb_host_interface *ifp, int num_ep,
+ unsigned char *buffer, int size)
{
unsigned char *buffer0 = buffer;
struct usb_endpoint_descriptor *d;
@@ -242,13 +291,10 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
goto skip_to_next_endpoint_or_interface_descriptor;
/* Check for duplicate endpoint addresses */
- for (i = 0; i < ifp->desc.bNumEndpoints; ++i) {
- if (ifp->endpoint[i].desc.bEndpointAddress ==
- d->bEndpointAddress) {
- dev_warn(ddev, "config %d interface %d altsetting %d has a duplicate endpoint with address 0x%X, skipping\n",
- cfgno, inum, asnum, d->bEndpointAddress);
- goto skip_to_next_endpoint_or_interface_descriptor;
- }
+ if (config_endpoint_is_duplicate(config, inum, asnum, d)) {
+ dev_warn(ddev, "config %d interface %d altsetting %d has a duplicate endpoint with address 0x%X, skipping\n",
+ cfgno, inum, asnum, d->bEndpointAddress);
+ goto skip_to_next_endpoint_or_interface_descriptor;
}
endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints];
@@ -522,8 +568,8 @@ static int usb_parse_interface(struct device *ddev, int cfgno,
if (((struct usb_descriptor_header *) buffer)->bDescriptorType
== USB_DT_INTERFACE)
break;
- retval = usb_parse_endpoint(ddev, cfgno, inum, asnum, alt,
- num_ep, buffer, size);
+ retval = usb_parse_endpoint(ddev, cfgno, config, inum, asnum,
+ alt, num_ep, buffer, size);
if (retval < 0)
return retval;
++n;
--
2.24.1
This is a note to let you know that I've just added the patch titled
tty: always relink the port
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 273f632912f1b24b642ba5b7eb5022e43a72f3b5 Mon Sep 17 00:00:00 2001
From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Date: Fri, 27 Dec 2019 17:44:34 +0000
Subject: tty: always relink the port
If the serial device is disconnected and reconnected, it re-enumerates
properly but does not link it. fwiw, linking means just saving the port
index, so allow it always as there is no harm in saving the same value
again even if it tries to relink with the same port.
Fixes: fb2b90014d78 ("tty: link tty and port before configuring it as console")
Reported-by: Kenneth R. Crudup <kenny(a)panix.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20191227174434.12057-1-sudipm.mukherjee@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/tty_port.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 5023c85ebc6e..044c3cbdcfa4 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -89,8 +89,7 @@ void tty_port_link_device(struct tty_port *port,
{
if (WARN_ON(index >= driver->num))
return;
- if (!driver->ports[index])
- driver->ports[index] = port;
+ driver->ports[index] = port;
}
EXPORT_SYMBOL_GPL(tty_port_link_device);
--
2.24.1
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e278af89f1ba0a9ef20947db6afc2c9afa37e85b
Gitweb: https://git.kernel.org/tip/e278af89f1ba0a9ef20947db6afc2c9afa37e85b
Author: Qian Cai <cai(a)lca.pw>
AuthorDate: Tue, 10 Dec 2019 22:30:42 -05:00
Committer: Borislav Petkov <bp(a)suse.de>
CommitterDate: Mon, 30 Dec 2019 19:25:59 +01:00
x86/resctrl: Fix an imbalance in domain_remove_cpu()
A system that supports resource monitoring may have multiple resources
while not all of these resources are capable of monitoring. Monitoring
related state is initialized only for resources that are capable of
monitoring and correspondingly this state should subsequently only be
removed from these resources that are capable of monitoring.
domain_add_cpu() calls domain_setup_mon_state() only when r->mon_capable
is true where it will initialize d->mbm_over. However,
domain_remove_cpu() calls cancel_delayed_work(&d->mbm_over) without
checking r->mon_capable resulting in an attempt to cancel d->mbm_over on
all resources, even those that never initialized d->mbm_over because
they are not capable of monitoring. Hence, it triggers a debugobjects
warning when offlining CPUs because those timer debugobjects are never
initialized:
ODEBUG: assert_init not available (active state 0) object type:
timer_list hint: 0x0
WARNING: CPU: 143 PID: 789 at lib/debugobjects.c:484
debug_print_object
Hardware name: HP Synergy 680 Gen9/Synergy 680 Gen9 Compute Module, BIOS I40 05/23/2018
RIP: 0010:debug_print_object
Call Trace:
debug_object_assert_init
del_timer
try_to_grab_pending
cancel_delayed_work
resctrl_offline_cpu
cpuhp_invoke_callback
cpuhp_thread_fun
smpboot_thread_fn
kthread
ret_from_fork
Fixes: e33026831bdb ("x86/intel_rdt/mbm: Handle counter overflow")
Signed-off-by: Qian Cai <cai(a)lca.pw>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Acked-by: Reinette Chatre <reinette.chatre(a)intel.com>
Cc: Fenghua Yu <fenghua.yu(a)intel.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: john.stultz(a)linaro.org
Cc: sboyd(a)kernel.org
Cc: <stable(a)vger.kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: tj(a)kernel.org
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: Vikas Shivappa <vikas.shivappa(a)linux.intel.com>
Cc: x86-ml <x86(a)kernel.org>
Link: https://lkml.kernel.org/r/20191211033042.2188-1-cai@lca.pw
---
arch/x86/kernel/cpu/resctrl/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 03eb90d..89049b3 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -618,7 +618,7 @@ static void domain_remove_cpu(int cpu, struct rdt_resource *r)
if (static_branch_unlikely(&rdt_mon_enable_key))
rmdir_mondata_subdir_allrdtgrp(r, d->id);
list_del(&d->list);
- if (is_mbm_enabled())
+ if (r->mon_capable && is_mbm_enabled())
cancel_delayed_work(&d->mbm_over);
if (is_llc_occupancy_enabled() && has_busy_rmid(r, d)) {
/*
Sasha,
On Mon, Dec 30, 2019 at 12:56:03AM +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: ce99091730c9 ("perf tools: Move strlcpy() from perf to tools/lib/string.c").
>
> The bot has tested the following trees: v5.4.6, v5.3.18, v4.19.91, v4.14.160, v4.9.207.
>
> v5.4.6: Build OK!
> v5.3.18: Build OK!
> v4.19.91: Failed to apply! Possible dependencies:
> 7bd330de43fd ("tools lib: Adopt skip_spaces() from the kernel sources")
>
> v4.14.160: Failed to apply! Possible dependencies:
> 7bd330de43fd ("tools lib: Adopt skip_spaces() from the kernel sources")
>
> v4.9.207: Failed to apply! Possible dependencies:
> 7bd330de43fd ("tools lib: Adopt skip_spaces() from the kernel sources")
> 96395cbbc7e9 ("tools lib string: Adopt prefixcmp() from perf and subcmd")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
Yes, there is a trivial conflict when this patch is applied to stable trees.
Do you need any help in resolving it?
Thanks,
Augmented Power Delivery Objects (A)PDO_s are used by USB-C
PD power adapters to advertize the voltages and currents
they support. There can be up to 7 PDO_s but before PPS
(programmable power supply) there were seldom more than 4
or 5. Recently Samsung released an optional PPS 45 Watt power
adapter (EP-TA485) that has 7 PDO_s. It is for the Galaxy 10+
tablet and charges it quicker than the adapter supplied at
purchase. The EP-TA485 causes an overzealous WARN_ON to soil
the log plus it miscalculates the number of bytes to read.
So this bug has been there for some time but goes
undetected for the majority of USB-C PD power adapters on
the market today that have 6 or less PDO_s. That may soon
change as more USB-C PD adapters with PPS come to market.
Tested on a EP-TA485 and an older Lenovo PN: SA10M13950
USB-C 65 Watt adapter (without PPS and has 4 PDO_s) plus
several other PD power adapters.
Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com>
---
drivers/usb/typec/tcpm/tcpci.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index c1f7073a56de..8b4ff9fff340 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -432,20 +432,30 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci)
if (status & TCPC_ALERT_RX_STATUS) {
struct pd_message msg;
- unsigned int cnt;
+ unsigned int cnt, payload_cnt;
u16 header;
regmap_read(tcpci->regmap, TCPC_RX_BYTE_CNT, &cnt);
+ /*
+ * 'cnt' corresponds to READABLE_BYTE_COUNT in section 4.4.14
+ * of the TCPCI spec [Rev 2.0 Ver 1.0 October 2017] and is
+ * defined in table 4-36 as one greater than the number of
+ * bytes received. And that number includes the header. So:
+ */
+ if (cnt > 3)
+ payload_cnt = cnt - (1 + sizeof(msg.header));
+ else
+ payload_cnt = 0;
tcpci_read16(tcpci, TCPC_RX_HDR, &header);
msg.header = cpu_to_le16(header);
- if (WARN_ON(cnt > sizeof(msg.payload)))
- cnt = sizeof(msg.payload);
+ if (WARN_ON(payload_cnt > sizeof(msg.payload)))
+ payload_cnt = sizeof(msg.payload);
- if (cnt > 0)
+ if (payload_cnt > 0)
regmap_raw_read(tcpci->regmap, TCPC_RX_DATA,
- &msg.payload, cnt);
+ &msg.payload, payload_cnt);
/* Read complete, clear RX status alert bit */
tcpci_write16(tcpci, TCPC_ALERT, TCPC_ALERT_RX_STATUS);
--
2.24.1
On Thu, Dec 26, 2019 at 12:55 AM Sasha Levin <sashal(a)kernel.org> wrote:
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.4.5, v5.3.18, v4.19.90, v4.14.159, v4.9.206, v4.4.206.
>
> v5.4.5: Build OK!
> v5.3.18: Build OK!
> v4.19.90: Build OK!
> v4.14.159: Failed to apply! Possible dependencies:
> 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers")
> fef6cc6b3618 ("media: v4l2-compat-ioctl32: fix several __user annotations")
>
> v4.9.206: Failed to apply! Possible dependencies:
> 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers")
> a56bc171598c ("[media] v4l: compat: Prevent allocating excessive amounts of memory")
> ba7ed691dcce ("[media] v4l2-compat-ioctl32: VIDIOC_S_EDID should return all fields on error")
> fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format")
> fef6cc6b3618 ("media: v4l2-compat-ioctl32: fix several __user annotations")
>
> v4.4.206: Failed to apply! Possible dependencies:
> 0579e6e3a326 ("doc-rst: linux_tv: remove whitespaces")
> 17defc282fe6 ("Documentation: add meta-documentation for Sphinx and kernel-doc")
> 22cba31bae9d ("Documentation/sphinx: add basic working Sphinx configuration and build")
> 234d549662a7 ("doc-rst: video: use reference for VIDIOC_ENUMINPUT")
> 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)")
> 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers")
> 7347081e8a52 ("doc-rst: linux_tv: simplify references")
> 789818845202 ("doc-rst: audio: Fix some cross references")
> 94fff0dc5333 ("doc-rst: dmx_fcalls: improve man-like format")
> 9e00ffca8cc7 ("doc-rst: querycap: fix troubles on some references")
> af4a4d0db8ab ("doc-rst: linux_tv: Replace reference names to match ioctls")
> c2b66cafdf02 ("[media] v4l: doc: Remove row numbers from tables")
> e6702ee18e24 ("doc-rst: app-pri: Fix a bad reference")
> fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
I think we need it to support users of musl on old kernels: musl is
adding conversion functions for emulating the new (time64) ioctl
commands on top of the old format, and without my patch, the
new commands do not necessarily return an error that musl can
catch.
I can provide a backport of my patch to v4.4 and v4.9 for this when
the patch has made it into mainline. Can you notify me again when
the time has come?
A related question that we should address is whether we want the v4l2
and alsa time64 ioctl patches backported as well, and to which kernels
(if any).
My feeling is that we don't want them those in v4.14 and earlier because
that is rather pointless with musl already having emulation in user space
and the rest of the kernel not being y2038 safe at all.
For v5.4 I'd say we do want them, and possibly all the other remaining
y2038 patches as well, I have a tree[1] that I try to keep up to date
with the versions that got posted and/or merged, as I know there is
demand for it. If you prefer not to have them in v5.4.y, I can keep them
here myself and make sure it's possible to my branch into that instead.
v4.19 is a bit borderline: if we decide to do the backports to v5.4 and
there is demand for v4.19.y, I could also try to pick the most important
patches from my tree and backport them to v4.19.0 (including a lot of
work that went into v5.1) and then look at that tree to see if it should
be part of the official v4.19.y or not.
Arnd
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…