This is a note to let you know that I've just added the patch titled
staging: most: net: fix buffer overflow
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-testing 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 be merged to the staging-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 4d1356ac12f4d5180d0df345d85ff0ee42b89c72 Mon Sep 17 00:00:00 2001
From: Andrey Shvetsov <andrey.shvetsov(a)k2l.de>
Date: Thu, 16 Jan 2020 18:22:39 +0100
Subject: staging: most: net: fix buffer overflow
If the length of the socket buffer is 0xFFFFFFFF (max size for an
unsigned int), then payload_len becomes 0xFFFFFFF1 after subtracting 14
(ETH_HLEN). Then, mdp_len is set to payload_len + 16 (MDP_HDR_LEN)
which overflows and results in a value of 2. These values for
payload_len and mdp_len will pass current buffer size checks.
This patch checks if derived from skb->len sum may overflow.
The check is based on the following idea:
For any `unsigned V1, V2` and derived `unsigned SUM = V1 + V2`,
`V1 + V2` overflows iif `SUM < V1`.
Reported-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Andrey Shvetsov <andrey.shvetsov(a)k2l.de>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20200116172238.6046-1-andrey.shvetsov@microchip.c…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/most/net/net.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/staging/most/net/net.c b/drivers/staging/most/net/net.c
index 8218c9a06cb5..5547e36e09de 100644
--- a/drivers/staging/most/net/net.c
+++ b/drivers/staging/most/net/net.c
@@ -82,6 +82,11 @@ static int skb_to_mamac(const struct sk_buff *skb, struct mbo *mbo)
unsigned int payload_len = skb->len - ETH_HLEN;
unsigned int mdp_len = payload_len + MDP_HDR_LEN;
+ if (mdp_len < skb->len) {
+ pr_err("drop: too large packet! (%u)\n", skb->len);
+ return -EINVAL;
+ }
+
if (mbo->buffer_length < mdp_len) {
pr_err("drop: too small buffer! (%d for %d)\n",
mbo->buffer_length, mdp_len);
@@ -129,6 +134,11 @@ static int skb_to_mep(const struct sk_buff *skb, struct mbo *mbo)
u8 *buff = mbo->virt_address;
unsigned int mep_len = skb->len + MEP_HDR_LEN;
+ if (mep_len < skb->len) {
+ pr_err("drop: too large packet! (%u)\n", skb->len);
+ return -EINVAL;
+ }
+
if (mbo->buffer_length < mep_len) {
pr_err("drop: too small buffer! (%d for %d)\n",
mbo->buffer_length, mep_len);
--
2.25.0
This fix is a case where a nv50 or gf100 graphics card is used on a VMD
Domain (or other memory restricted domain) that results in a
null-pointer dereference.
One of the original fixes was already backported:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=…
Sushma Kalakota (3):
drm/nouveau/bar/nv50: check bar1 vmm return value
drm/nouveau/bar/gf100: ensure BAR is mapped
drm/nouveau/mmu: qualify vmm during dtor
drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
--
2.17.1
The following dtbs build error noticed for arm build on stable rc 4.19 branch.
# make -sk KBUILD_BUILD_USER=KernelCI -C/linux ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc O=build dtbs
#
../arch/arm/boot/dts/imx6dl-icore-mipi.dts:11:10: fatal error:
imx6qdl-icore-1.5.dtsi: No such file or directory
11 | #include "imx6qdl-icore-1.5.dtsi"
| ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.lib:294:
arch/arm/boot/dts/imx6dl-icore-mipi.dtb] Error 1
On Thu, 9 Jan 2020 at 13:16, Shawn Guo <shawnguo(a)kernel.org> wrote:
>
> On Mon, Dec 30, 2019 at 05:30:19PM +0530, Jagan Teki wrote:
> > The EDIMM STARTER KIT i.Core 1.5 MIPI Evaluation is based on
> > the 1.5 version of the i.Core MX6 cpu module. The 1.5 version
> > differs from the original one for a few details, including the
> > ethernet PHY interface clock provider.
> >
> > With this commit, the ethernet interface works properly:
> > SMSC LAN8710/LAN8720 2188000.ethernet-1:00: attached PHY driver
> >
> > While before using the 1.5 version, ethernet failed to startup
> > do to un-clocked PHY interface:
> > fec 2188000.ethernet eth0: could not attach to PHY
> >
> > Similar fix has merged for i.Core MX6Q but missed to update for DL.
> >
> > Fixes: a8039f2dd089 ("ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support")
> > Cc: Jacopo Mondi <jacopo(a)jmondi.org>
> > Signed-off-by: Michael Trimarchi <michael(a)amarulasolutions.com>
> > Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com>
>
> Applied all 3, thanks.
It is possible for archdata.iommu to be set to
DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO so check for
those values before calling __dmar_remove_one_dev_info. Without a
check it can result in a null pointer dereference. This has been seen
while booting a kdump kernel on an HP dl380 gen9.
Cc: Joerg Roedel <joro(a)8bytes.org>
Cc: Lu Baolu <baolu.lu(a)linux.intel.com>
Cc: David Woodhouse <dwmw2(a)infradead.org>
Cc: stable(a)vger.kernel.org # 5.3+
Cc: linux-kernel(a)vger.kernel.org
Fixes: ae23bfb68f28 ("iommu/vt-d: Detach domain before using a private one")
Signed-off-by: Jerry Snitselaar <jsnitsel(a)redhat.com>
---
drivers/iommu/intel-iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 1801f0aaf013..932267f49f9a 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -5163,7 +5163,8 @@ static void dmar_remove_one_dev_info(struct device *dev)
spin_lock_irqsave(&device_domain_lock, flags);
info = dev->archdata.iommu;
- if (info)
+ if (info && info != DEFER_DEVICE_DOMAIN_INFO
+ && info != DUMMY_DEVICE_DOMAIN_INFO)
__dmar_remove_one_dev_info(info);
spin_unlock_irqrestore(&device_domain_lock, flags);
}
--
2.24.0
Hi Sasha,
As this patch is based on commit f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs") which was introduced in 4.14.
So, this patch is not applicable for kernel versions prior to 4.14.
As this patch is under review, can we put it on hold ?
Regards,
Vipul
-----Original Message-----
From: Sasha Levin [mailto:sashal@kernel.org]
Sent: 22 January 2020 07:56
To: Sasha Levin <sashal(a)kernel.org>; Vipul Kumar <vipulk0511(a)gmail.com>; Kumar, Vipul <Vipul_Kumar(a)mentor.com>; Daniel Lezcano <daniel.lezcano(a)linaro.org>
Cc: linux-kernel(a)vger.kernel.org; Stable <stable(a)vger.kernel.org>; stable(a)vger.kernel.org; stable(a)vger.kernel.org
Subject: Re: [v3] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC
Hi,
[This is an automated email]
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.13, v4.19.97, v4.14.166, v4.9.210, v4.4.210.
v5.4.13: Build OK!
v4.19.97: Build OK!
v4.14.166: Build failed! Errors:
v4.9.210: Failed to apply! Possible dependencies:
f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs")
v4.4.210: Failed to apply! Possible dependencies:
0007bccc3cfd ("x86: Replace RDRAND forced-reseed with simple sanity check")
07dc900e17a9 ("perf/x86: Move Kconfig.perf and other perf configuration bits to events/Kconfig")
1b74dde7c47c ("x86/cpu: Convert printk(KERN_<LEVEL> ...) to pr_<level>(...)")
218cfe4ed888 ("perf/x86: Move perf_event_amd_ibs.c ....... => x86/events/amd/ibs.c")
39b0332a2158 ("perf/x86: Move perf_event_amd.c ........... => x86/events/amd/core.c")
442f5c74cbea ("perf/x86: Use INST_RETIRED.TOTAL_CYCLES_PS for cycles:pp for Skylake")
5b26547dd7fa ("perf/x86: Move perf_event_amd_iommu.[ch] .. => x86/events/amd/iommu.[ch]")
724697648eec ("perf/x86: Use INST_RETIRED.PREC_DIST for cycles: ppp")
e633c65a1d58 ("x86/perf/intel/uncore: Make the Intel uncore PMU driver modular")
fa9cbf320e99 ("perf/x86: Move perf_event.c ............... => x86/events/core.c")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
On Wed, 22 Jan 2020 02:26:22 +0000
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: 30350d65ac56 ("tracing: Add variable support to hist triggers").
>
> The bot has tested the following trees: v5.4.13, v4.19.97.
>
> v5.4.13: Build OK!
> v4.19.97: Build failed! Errors:
> kernel/trace/trace_events_hist.c:5725:34: error: macro "list_for_each_entry_rcu" passed 4 arguments, but takes just 3
> kernel/trace/trace_events_hist.c:5724:2: error: ‘list_for_each_entry_rcu’ undeclared (first use in this function)
> kernel/trace/trace_events_hist.c:5724:25: error: expected ‘;’ before ‘{’ token
Ah, that depends on commit 28875945ba98 ("rcu: Add support for consolidated-RCU reader checking").
We need to remove lockdep_is_held() from that list_for_each_entry_rcu().
(I've attached it)
Thank you,
--
Masami Hiramatsu <mhiramat(a)kernel.org>