November 2021 - Linux-stable-mirror

FAILED: patch "[PATCH] usb: dwc3: gadget: Fix null pointer exception" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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 26288448120b28af1dfd85a6fa6b6d55a16c7f2f Mon Sep 17 00:00:00 2001 From: Albert Wang <albertccwang(a)google.com> Date: Tue, 9 Nov 2021 17:26:42 +0800 Subject: [PATCH] usb: dwc3: gadget: Fix null pointer exception In the endpoint interrupt functions dwc3_gadget_endpoint_transfer_in_progress() and dwc3_gadget_endpoint_trbs_complete() will dereference the endpoint descriptor. But it could be cleared in __dwc3_gadget_ep_disable() when accessory disconnected. So we need to check whether it is null or not before dereferencing it. Fixes: f09ddcfcb8c5 ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers") Cc: stable <stable(a)vger.kernel.org> Reviewed-by: Jack Pham <quic_jackp(a)quicinc.com> Signed-off-by: Albert Wang <albertccwang(a)google.com> Link: https://lore.kernel.org/r/20211109092642.3507692-1-albertccwang@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index daa8f8548a2e..7e3db00e9759 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3263,6 +3263,9 @@ static bool dwc3_gadget_endpoint_trbs_complete(struct dwc3_ep *dep, struct dwc3 *dwc = dep->dwc; bool no_started_trb = true; + if (!dep->endpoint.desc) + return no_started_trb; + dwc3_gadget_ep_cleanup_completed_requests(dep, event, status); if (dep->flags & DWC3_EP_END_TRANSFER_PENDING) @@ -3310,6 +3313,9 @@ static void dwc3_gadget_endpoint_transfer_in_progress(struct dwc3_ep *dep, { int status = 0; + if (!dep->endpoint.desc) + return; + if (usb_endpoint_xfer_isoc(dep->endpoint.desc)) dwc3_gadget_endpoint_frame_from_event(dep, event);

3 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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 63c4c320ccf77074ffe9019ac596603133c1b517 Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Mon, 25 Oct 2021 16:35:06 -0700 Subject: [PATCH] usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer The programming guide noted that the driver needs to verify if the link state is in U0 before executing the Start Transfer command. If it's not in U0, the driver needs to perform remote wakeup. This is not accurate. If the link state is in U1/U2, then the controller will not respond to link recovery request from DCTL.ULSTCHNGREQ. The Start Transfer command will trigger a link recovery if it is in U1/U2. A clarification will be added to the programming guide for all controller versions. The current implementation shouldn't cause any functional issue. It may occasionally report an invalid time out warning from failed link recovery request. The driver will still go ahead with the Start Transfer command if the remote wakeup fails. The new change only initiates remote wakeup where it is needed, which is when the link state is in L1/L2/U3. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/05b4a5fbfbd0863fc9b1d7af934a366219e3d0b4.16352047… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 3d6f4adaa15a..daa8f8548a2e 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -310,13 +310,24 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) { int link_state; + /* + * Initiate remote wakeup if the link state is in U3 when + * operating in SS/SSP or L1/L2 when operating in HS/FS. If the + * link state is in U1/U2, no remote wakeup is needed. The Start + * Transfer command will initiate the link recovery. + */ link_state = dwc3_gadget_get_link_state(dwc); - if (link_state == DWC3_LINK_STATE_U1 || - link_state == DWC3_LINK_STATE_U2 || - link_state == DWC3_LINK_STATE_U3) { + switch (link_state) { + case DWC3_LINK_STATE_U2: + if (dwc->gadget->speed >= USB_SPEED_SUPER) + break; + + fallthrough; + case DWC3_LINK_STATE_U3: ret = __dwc3_gadget_wakeup(dwc); dev_WARN_ONCE(dwc->dev, ret, "wakeup failed --> %d\n", ret); + break; } }

3 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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 63c4c320ccf77074ffe9019ac596603133c1b517 Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Mon, 25 Oct 2021 16:35:06 -0700 Subject: [PATCH] usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer The programming guide noted that the driver needs to verify if the link state is in U0 before executing the Start Transfer command. If it's not in U0, the driver needs to perform remote wakeup. This is not accurate. If the link state is in U1/U2, then the controller will not respond to link recovery request from DCTL.ULSTCHNGREQ. The Start Transfer command will trigger a link recovery if it is in U1/U2. A clarification will be added to the programming guide for all controller versions. The current implementation shouldn't cause any functional issue. It may occasionally report an invalid time out warning from failed link recovery request. The driver will still go ahead with the Start Transfer command if the remote wakeup fails. The new change only initiates remote wakeup where it is needed, which is when the link state is in L1/L2/U3. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/05b4a5fbfbd0863fc9b1d7af934a366219e3d0b4.16352047… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 3d6f4adaa15a..daa8f8548a2e 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -310,13 +310,24 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) { int link_state; + /* + * Initiate remote wakeup if the link state is in U3 when + * operating in SS/SSP or L1/L2 when operating in HS/FS. If the + * link state is in U1/U2, no remote wakeup is needed. The Start + * Transfer command will initiate the link recovery. + */ link_state = dwc3_gadget_get_link_state(dwc); - if (link_state == DWC3_LINK_STATE_U1 || - link_state == DWC3_LINK_STATE_U2 || - link_state == DWC3_LINK_STATE_U3) { + switch (link_state) { + case DWC3_LINK_STATE_U2: + if (dwc->gadget->speed >= USB_SPEED_SUPER) + break; + + fallthrough; + case DWC3_LINK_STATE_U3: ret = __dwc3_gadget_wakeup(dwc); dev_WARN_ONCE(dwc->dev, ret, "wakeup failed --> %d\n", ret); + break; } }

3 years, 1 month

1
0
0 0

[PATCH] powerpc/mm: fix early initialization failure for MMUs with no hash table

by Vladimir Oltean

The blamed patch attempted to do a trivial conversion of map_mem_in_cams() by adding an extra "bool init" argument, but by mistake, changed the way in which two call sites pass the other boolean argument, "bool dry_run". As a result, early_init_this_mmu() now calls map_mem_in_cams() with dry_run=true, and setup_initial_memory_limit() calls with dry_run=false, both of which are unintended changes. This makes the kernel boot process hang here: [ 0.045211] e500 family performance monitor hardware support registered [ 0.051891] rcu: Hierarchical SRCU implementation. [ 0.057791] smp: Bringing up secondary CPUs ... Issue noticed on a Freescale T1040. Fixes: 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if init is done") Cc: stable(a)vger.kernel.org Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> --- arch/powerpc/mm/nohash/tlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c index 89353d4f5604..647bf454a0fa 100644 --- a/arch/powerpc/mm/nohash/tlb.c +++ b/arch/powerpc/mm/nohash/tlb.c @@ -645,7 +645,7 @@ static void early_init_this_mmu(void) if (map) linear_map_top = map_mem_in_cams(linear_map_top, - num_cams, true, true); + num_cams, false, true); } #endif @@ -766,7 +766,7 @@ void setup_initial_memory_limit(phys_addr_t first_memblock_base, num_cams = (mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) / 4; linear_sz = map_mem_in_cams(first_memblock_size, num_cams, - false, true); + true, true); ppc64_rma_size = min_t(u64, linear_sz, 0x40000000); } else -- 2.25.1

3 years, 1 month

2
2
0 0

[PATCH v3 1/1] staging: ion: Prevent incorrect reference counting behavour

by Lee Jones

Supply additional checks in order to prevent unexpected results. Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf") Suggested-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- Destined for v4.4.y and v4.9.y drivers/staging/android/ion/ion.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 806e9b30b9dc8..aac9b38b8c25c 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -489,6 +489,9 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer) void *vaddr; if (buffer->kmap_cnt) { + if (buffer->kmap_cnt == INT_MAX) + return ERR_PTR(-EOVERFLOW); + buffer->kmap_cnt++; return buffer->vaddr; } @@ -509,6 +512,9 @@ static void *ion_handle_kmap_get(struct ion_handle *handle) void *vaddr; if (handle->kmap_cnt) { + if (handle->kmap_cnt == INT_MAX) + return ERR_PTR(-EOVERFLOW); + handle->kmap_cnt++; return buffer->vaddr; } -- 2.34.0.rc2.393.gf8c9666880-goog

3 years, 1 month

3
2
0 0

Re: [Regression][Stable] sd use scsi_mode_sense with invalid param

by Tom Yan

Hi Greg, Could you help pulling c749301ebee82eb5e97dec14b6ab31a4aabe37a6 into the stable branches in which 17b49bcbf8351d3dbe57204468ac34f033ed60bc has been pulled? Thanks! Regards, Tom On Sat, 27 Nov 2021 at 05:21, Tom Yan <tom.ty89(a)gmail.com> wrote: > > Ahh, looks like the required change to sd > (c749301ebee82eb5e97dec14b6ab31a4aabe37a6) has been added to upstream > but somehow got missed when 17b49bcbf8351d3dbe57204468ac34f033ed60bc > was pulled into stable... > > On Sat, 27 Nov 2021 at 05:11, Tom Yan <tom.ty89(a)gmail.com> wrote: > > > > Hi, > > > > So with 17b49bcbf8351d3dbe57204468ac34f033ed60bc (upstream), > > scsi_mode_sense now returns -EINVAL if len < 8, yet in sd, the first mode > > sense attempted by sd_read_cache_type() is done with (first_)len being > > 4, which results in the failure of the attempt. > > > > Since the commit is merged into stable, my SATA drive (that has > > volatile write cache) is assumed to be a "write through" drive after I > > upgraded from 5.15.4 to 5.15.5, as libata sets use_10_for_ms to 1. > > > > Since sd does not (get to) determine which mode sense command to use, > > should scsi_mode_sense at least accept a special value 0 (which > > first_len would be set to), which is use to refers to the minimum len > > to use for mode sense 6 and 10 respectively (i.e. 4 or 8)? > > > > Regards, > > Tom

3 years, 1 month

3
2
0 0

Your comments have been submitted to the Yukon Hospital Corporation

by Yukon Hospital Corporation via Yukon Hospital Corporation

Thank you for submitting your feedback to the Yukon Hospital Corporation. If you have requested a response from us, we will get back to you as soon as we can. Following is a transcript of the message you submitted. Submitted on Saturday, November 27, 2021 - 04:45 Submitted values are: Your Name: ❤️ Alice sent you a hot video! Watch Here: https://bit.ly/3113Lyn?y7m ❤️ Your Email: stable(a)vger.kernel.org Your Phone Number: 193327175625 Would you like to be contacted regarding your feedback? No Which hospital does your feedback pertain to? Watson Lake Community Hospital Subject: sy9qh1dw Message: smf83sa

3 years, 1 month

1
0
0 0

[PATCH -next V5 2/2] sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl

by Baokun Li

Trying to remove the fsl-sata module in the PPC64 GNU/Linux leads to the following warning: ------------[ cut here ]------------ remove_proc_entry: removing non-empty directory 'irq/69', leaking at least 'fsl-sata[ff0221000.sata]' WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 .remove_proc_entry+0x20c/0x220 IRQMASK: 0 NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 LR [c000000000338268] .remove_proc_entry+0x208/0x220 Call Trace: .remove_proc_entry+0x208/0x220 (unreliable) .unregister_irq_proc+0x104/0x140 .free_desc+0x44/0xb0 .irq_free_descs+0x9c/0xf0 .irq_dispose_mapping+0x64/0xa0 .sata_fsl_remove+0x58/0xa0 [sata_fsl] .platform_drv_remove+0x40/0x90 .device_release_driver_internal+0x160/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] ---[ end trace 0ea876d4076908f5 ]--- The driver creates the mapping by calling irq_of_parse_and_map(), so it also has to dispose the mapping. But the easy way out is to simply use platform_get_irq() instead of irq_of_parse_map(). Also we should adapt return value checking and propagate error values. In this case the mapping is not managed by the device but by the of core, so the device has not to dispose the mapping. Fixes: faf0b2e5afe7 ("drivers/ata: add support to Freescale 3.0Gbps SATA Controller") Cc: stable(a)vger.kernel.org Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- V1->V2: Adapt return value checking and propagate error values. V2->V3: Add fixed and CC stable. V4->V5: Delete duplicate dev_err() message. drivers/ata/sata_fsl.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index 2eb216792695..3b31a4f596d8 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c @@ -1490,9 +1490,9 @@ static int sata_fsl_probe(struct platform_device *ofdev) host_priv->ssr_base = ssr_base; host_priv->csr_base = csr_base; - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); - if (!irq) { - dev_err(&ofdev->dev, "invalid irq from platform\n"); + irq = platform_get_irq(ofdev, 0); + if (irq < 0) { + retval = irq; goto error_exit_with_cleanup; } host_priv->irq = irq; @@ -1567,8 +1567,6 @@ static int sata_fsl_remove(struct platform_device *ofdev) ata_host_detach(host); - irq_dispose_mapping(host_priv->irq); - return 0; } -- 2.31.1

3 years, 1 month

3
2
0 0

[PATCH -next V5 1/2] sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl

by Baokun Li

When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Call Trace: .free_irq+0x1c/0x4e0 (unreliable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 ================================================================== The triggering of the BUG is shown in the following stack: driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host) The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should not be executed in drv->remove. These functions should be executed in host_stop after port_stop. Therefore, we move these functions to the new function sata_fsl_host_stop and bind the new function to host_stop. Fixes: faf0b2e5afe7 ("drivers/ata: add support to Freescale 3.0Gbps SATA Controller") Cc: stable(a)vger.kernel.org Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- V2->V3: Add fixed and CC stable and modified the patch description. V3->V4: Use a single structure. drivers/ata/sata_fsl.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index e5838b23c9e0..2eb216792695 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c @@ -1394,6 +1394,14 @@ static int sata_fsl_init_controller(struct ata_host *host) return 0; } +static void sata_fsl_host_stop(struct ata_host *host) +{ + struct sata_fsl_host_priv *host_priv = host->private_data; + + iounmap(host_priv->hcr_base); + kfree(host_priv); +} + /* * scsi mid-layer and libata interface structures */ @@ -1426,6 +1434,8 @@ static struct ata_port_operations sata_fsl_ops = { .port_start = sata_fsl_port_start, .port_stop = sata_fsl_port_stop, + .host_stop = sata_fsl_host_stop, + .pmp_attach = sata_fsl_pmp_attach, .pmp_detach = sata_fsl_pmp_detach, }; @@ -1558,8 +1568,6 @@ static int sata_fsl_remove(struct platform_device *ofdev) ata_host_detach(host); irq_dispose_mapping(host_priv->irq); - iounmap(host_priv->hcr_base); - kfree(host_priv); return 0; } -- 2.31.1

3 years, 1 month

3
2
0 0

stable/linux-4.4.y baseline: 87 runs, 1 regressions (v4.4.293)

by kernelci.org bot

stable/linux-4.4.y baseline: 87 runs, 1 regressions (v4.4.293) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/job/stable/branch/linux-4.4.y/kernel/v4.4.293/pla… Test: baseline Tree: stable Branch: linux-4.4.y Describe: v4.4.293 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git SHA: ae6f8ce9b7496a4ffd3ba545f824b44cdb217149 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/61a14b5846bf10ffb718f6d1 Results: 4 PASS, 1 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-4.4.y/v4.4.293/arm/omap2plus_def… HTML log: https://storage.kernelci.org//stable/linux-4.4.y/v4.4.293/arm/omap2plus_def… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/61a14b5846bf10ffb718f6d7 new failure (last pass: v4.4.292) 2 lines 2021-11-26T21:01:57.369622 [ 19.265441] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=pass UNITS=lines MEASUREMENT=0> 2021-11-26T21:01:57.412658 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/115 2021-11-26T21:01:57.421715 kern :emerg : lock: emif_lock+0x0/0xfffff25c [emif], .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1

3 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2021