- Linux-stable-mirror - lists.linaro.org

patch "mei: me: add comet point (lake) H device ids" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: me: add comet point (lake) H device ids to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-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 char-misc-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 559e575a8946a6561dfe8880de341d4ef78d5994 Mon Sep 17 00:00:00 2001 From: Tomas Winkler <tomas.winkler(a)intel.com> Date: Sun, 19 Jan 2020 11:42:29 +0200 Subject: mei: me: add comet point (lake) H device ids Add Comet Point device IDs for Comet Lake H platforms. Cc: <stable(a)vger.kernel.org> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Link: https://lore.kernel.org/r/20200119094229.20116-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/hw-me-regs.h | 4 ++++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 6 insertions(+) diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h index 7cd67fb2365d..9d24db38e8bc 100644 --- a/drivers/misc/mei/hw-me-regs.h +++ b/drivers/misc/mei/hw-me-regs.h @@ -81,8 +81,12 @@ #define MEI_DEV_ID_CMP_LP 0x02e0 /* Comet Point LP */ #define MEI_DEV_ID_CMP_LP_3 0x02e4 /* Comet Point LP 3 (iTouch) */ + #define MEI_DEV_ID_CMP_V 0xA3BA /* Comet Point Lake V */ +#define MEI_DEV_ID_CMP_H 0x06e0 /* Comet Lake H */ +#define MEI_DEV_ID_CMP_H_3 0x06e4 /* Comet Lake H 3 (iTouch) */ + #define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */ #define MEI_DEV_ID_TGP_LP 0xA0E0 /* Tiger Lake Point LP */ diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index c845b7e40f26..c14261d735db 100644 --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -99,6 +99,8 @@ static const struct pci_device_id mei_me_pci_tbl[] = { {MEI_PCI_DEVICE(MEI_DEV_ID_CMP_LP, MEI_ME_PCH12_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_CMP_LP_3, MEI_ME_PCH8_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_CMP_V, MEI_ME_PCH12_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CMP_H, MEI_ME_PCH12_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CMP_H_3, MEI_ME_PCH8_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)}, -- 2.25.0

5 years, 7 months

1
0
0 0

[PATCH RESEND RESEND] media: uvc: Avoid cyclic entity chains due to malformed USB descriptors

by Will Deacon

Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked up the following WARNING from the UVC chain scanning code: | list_add double add: new=ffff880069084010, prev=ffff880069084010, | next=ffff880067d22298. | ------------[ cut here ]------------ | WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0 | Modules linked in: | CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted | 4.14.0-rc2-42613-g1488251d1a98 #238 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 | Workqueue: usb_hub_wq hub_event | task: ffff88006b01ca40 task.stack: ffff880064358000 | RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29 | RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286 | RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000 | RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac | RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000 | R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010 | R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0 | FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 | CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 | CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0 | Call Trace: | __list_add ./include/linux/list.h:59 | list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92 | uvc_scan_chain_forward.isra.8+0x373/0x416 | drivers/media/usb/uvc/uvc_driver.c:1471 | uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585 | uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769 | uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104 Looking into the output from usbmon, the interesting part is the following data packet: ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080 00090403 00000e01 00000924 03000103 7c003328 010204db If we drop the lead configuration and interface descriptors, we're left with an output terminal descriptor describing a generic display: /* Output terminal descriptor */ buf[0] 09 buf[1] 24 buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */ buf[3] 00 /* ID */ buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */ buf[5] 03 buf[6] 7c buf[7] 00 /* source ID refers to self! */ buf[8] 33 The problem with this descriptor is that it is self-referential: the source ID of 0 matches itself! This causes the 'struct uvc_entity' representing the display to be added to its chain list twice during 'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is processed directly from the 'dev->entities' list and then again immediately afterwards when trying to follow the source ID in 'uvc_scan_chain_forward()' Add a check before adding an entity to a chain list to ensure that the entity is not already part of a chain. Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Kostya Serebryany <kcc(a)google.com> Cc: <stable(a)vger.kernel.org> Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Reported-by: Andrey Konovalov <andreyknvl(a)google.com> Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa… Signed-off-by: Will Deacon <will(a)kernel.org> --- That's right, it's the same patch again! No changes since either of: http://lkml.kernel.org/r/20191002112753.21630-1-will@kernel.org https://lore.kernel.org/lkml/20191016195800.22099-1-will@kernel.org Please consider merging. drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 66ee168ddc7e..e24420b1750a 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1493,6 +1493,11 @@ static int uvc_scan_chain_forward(struct uvc_video_chain *chain, break; if (forward == prev) continue; + if (forward->chain.next || forward->chain.prev) { + uvc_trace(UVC_TRACE_DESCR, "Found reference to " + "entity %d already in chain.\n", forward->id); + return -EINVAL; + } switch (UVC_ENTITY_TYPE(forward)) { case UVC_VC_EXTENSION_UNIT: @@ -1574,6 +1579,13 @@ static int uvc_scan_chain_backward(struct uvc_video_chain *chain, return -1; } + if (term->chain.next || term->chain.prev) { + uvc_trace(UVC_TRACE_DESCR, "Found reference to " + "entity %d already in chain.\n", + term->id); + return -EINVAL; + } + if (uvc_trace_param & UVC_TRACE_PROBE) printk(KERN_CONT " %d", term->id); -- 2.24.0.rc1.363.gb1bccd3e3d-goog

5 years, 7 months

4
12
0 0

patch "staging: most: net: fix buffer overflow" added to staging-testing

by gregkh＠linuxfoundation.org

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

5 years, 7 months

1
0
0 0

[BACKPORT v4.19 0/3] Fixes for nv50/gf100 under VMD

by Sushma Kalakota

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

5 years, 7 months

2
4
0 0

Re: [PATCH v2 1/3] ARM: dts: imx6q-icore-mipi: Use 1.5 version of i.Core MX6DL

by Naresh Kamboju

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.

5 years, 7 months

3
2
0 0

[PATCH] iommu/vt-d: call __dmar_remove_one_dev_info with valid pointer

by Jerry Snitselaar

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

5 years, 7 months

2
1
0 0

stable-rc/linux-4.9.y boot: 53 boots: 2 failed, 51 passed (v4.9.210-90-ge20d090cbbfe)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 53 boots: 2 failed, 51 passed (v4.9.210-90-ge20d090cbbfe) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.210-90-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.210-90-ge20d090cbbfe Git Commit: e20d090cbbfefd4e4f49fbd3b5535ef965533294 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 28 unique boards, 13 SoC families, 10 builds out of 183 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: alpine-db: lab-baylibre: new failure (last pass: v4.9.210) Boot Failures Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab multi_v7_defconfig: gcc-8: alpine-db: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

RE: [v3] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

by Kumar, Vipul

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

5 years, 8 months

1
0
0 0

stable-rc/linux-4.19.y boot: 57 boots: 1 failed, 53 passed with 3 untried/unknown (v4.19.97-88-g854a2a8f9451)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 57 boots: 1 failed, 53 passed with 3 untried/unknown (v4.19.97-88-g854a2a8f9451) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.97-88… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.97-88-g854a2a8f9451 Git Commit: 854a2a8f9451c77029355b3ca1cf0c963aaaffd5 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 14 SoC families, 13 builds out of 206 Boot Regressions Detected: arc: hsdk_defconfig: gcc-8: hsdk: lab-baylibre: new failure (last pass: v4.19.97-66-g6e319a78bc27) arm: sunxi_defconfig: gcc-8: sun4i-a10-olinuxino-lime: lab-baylibre: new failure (last pass: v4.19.97-66-g6e319a78bc27) Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

stable-rc/linux-4.4.y boot: 37 boots: 1 failed, 36 passed (v4.4.210-70-ga43a787c971a)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 37 boots: 1 failed, 36 passed (v4.4.210-70-ga43a787c971a) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.210-70-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.210-70-ga43a787c971a Git Commit: a43a787c971af563b4ae7d2e96f5c35e04b37456 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 22 unique boards, 11 SoC families, 7 builds out of 182 Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror