June 2024 - Linux-stable-mirror

Candidates for stable v6.9..v6.10-rc3 Use after free

by Ronnie Sahlberg

Here is a list of potential Use after free that are not yet in linux-running-stable The list has been manually pruned and I believe they are all genuine issues. 546ceb1dfdac866648ec 36c92936e868601fa1f4 4e7aaa6b82d63e8ddcbf 2884dc7d08d98a89d8d6 166fcf86cd34e15c7f38 4b4391e77a6bf24cba2e da4a827416066191aafe de3e26f9e5b76fc62807 0fc75c5940fa634d84e6 647535760a00a854c185 a4edf675ba3357f60e2e 90e823498881fb8a91d8 2c6b531020f0590db3b6 7172dc93d621d5dc302d 86735b57c905e775f05d 795bb82d12a16a4cee42 2ecd487b670fcbb1ad48 -- Ronnie Sahlberg [Principal Software Engineer, Linux] P 775 384 8203 | E [email] | W ciq.com

6 months, 3 weeks

2
1
0 0

Candidates for stable v6.9..v6.10-rc3 Kernel Panic

by Ronnie Sahlberg

The following is a pruned list of commits from upstream v6.9..v6.10-rc3 that looks like genuine kernel panics. As far as I can tell these are not yet in linux-rolling-stable If there are issues with the list or things I cna improve when pruning the list please let me know a6736a0addd60fccc3a3 79f18a41dd056115d685 8eef5c3cea65f248c99c 12cda920212a49fa22d9 b01e1c030770ff3b4fe3 744d197162c2070a6045 3f0c44c8c21cfa3bb6b7 0105eaabb27f31d9b8d3 6434e69814b159608a23 d38e48563c1f70460503 c8b3f38d2dae03979448 33afbfcc105a57215975 491aee894a08bc9b8bb5 d0d1df8ba18abc57f28f ffbe335b8d471f79b259 93c1800b3799f1737598 3c34fb0bd4a4237592c5 ffb9072bce200a4d0040 9dedabe95b49ec9b0d16 788e4c75f831d06fcfbb 642f89daa34567d02f31 f55cd31287e5f77f226c 6ca445d8af0ed5950ebf ed281c6ab6eb8a914f06 e8dc41afca161b988e6d c6a6c9694aadc4c3ab8d eebadafc3b14d9426fa9 29b4c7bb8565118e2c7e da0e01cc7079124cb1e8 b66c079aabdff3954e93 514ca22a25265e9bef10 05090ae82f44570fefdd 3b89ec41747a6b6b8c7b 57787fa42f9fc12fe189 1af2dface5d286dd1f2f 81bf14519a8ca17af4f0 991b5e2aad870828669c 17b0dfa1f35bf58c17ae -- Ronnie Sahlberg [Principal Software Engineer, Linux] P 775 384 8203 | E [email] | W ciq.com

6 months, 3 weeks

2
1
0 0

Candidates for stable v6.9..v6.10-rc3 Deadlock

by Ronnie Sahlberg

Pruned list of commits that look like genuine deadlocks that are not yet in linux-rolling-stable 44c06bbde6443de206b3 8c2f5dd0c362ec036f02 e57f2187ccc125f1f14f 67ec8cdf29971677b2fb -- Ronnie Sahlberg [Principal Software Engineer, Linux] P 775 384 8203 | E [email] | W ciq.com

6 months, 3 weeks

2
1
0 0

Candidates for stable v6.9..v6.10-rc3 NULL pointers

by Ronnie Sahlberg

Manually checked list of commits in upstream that mention NULL pointers and that reference that they fix a commit that is in linux-running-stable. a9b9741854a9fe9df948 c4ab9da85b9df3692f86 c44711b78608c98a3e6b 0dcc53abf58d572d34c5 445c0b69c72903528fdf 97ab3e8eec0ce79d9e26 47558cbaa842c4561d08 62cbabc6fd228e62daff 02367f52901932674ff2 -- Ronnie Sahlberg [Principal Software Engineer, Linux] P 775 384 8203 | E [email] | W ciq.com

6 months, 3 weeks

2
1
0 0

Re: Patch "driver core: platform: Emit a warning if a remove callback returned non-zero" has been added to the 5.10-stable tree

by Uwe Kleine-König

Hello Sasha, On 6/16/24 04:18, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > driver core: platform: Emit a warning if a remove callback returned non-zero > > to the 5.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > driver-core-platform-emit-a-warning-if-a-remove-call.patch > and it can be found in the queue-5.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 2f1ac60bc9668567f021c314312563951039f77b > Author: Uwe Kleine-König <uwe(a)kleine-koenig.org> > Date: Sun Feb 7 22:15:37 2021 +0100 > > driver core: platform: Emit a warning if a remove callback returned non-zero > > [ Upstream commit e5e1c209788138f33ca6558bf9f572f6904f486d ] > > The driver core ignores the return value of a bus' remove callback. However > a driver returning an error code is a hint that there is a problem, > probably a driver author who expects that returning e.g. -EBUSY has any > effect. > > The right thing to do would be to make struct platform_driver::remove() > return void. With the immense number of platform drivers this is however a > big quest and I hope to prevent at least a few new drivers that return an > error code here. > > Signed-off-by: Uwe Kleine-König <uwe(a)kleine-koenig.org> > Link: https://lore.kernel.org/r/20210207211537.19992-1-uwe@kleine-koenig.org > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Stable-dep-of: 55c421b36448 ("mmc: davinci: Don't strip remove function when driver is builtin") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> That looks wrong. If this patch should be included in stable, it shouldn't be because it's a dependency. 55c421b36448 works without this patch for sure. Either backport e5e1c2097881 because you think that warning should be in 5.10.x, or don't backport it. Best regards Uwe

6 months, 3 weeks

2
1
0 0

[PATCH v2] ata: ahci: Do not enable LPM if no LPM states are supported by the HBA

by Niklas Cassel

LPM consists of HIPM (host initiated power management) and DIPM (device initiated power management). ata_eh_set_lpm() will only enable HIPM if both the HBA and the device supports it. However, DIPM will be enabled as long as the device supports it. The HBA will later reject the device's request to enter a power state that it does not support (Slumber/Partial/DevSleep) (DevSleep is never initiated by the device). For a HBA that doesn't support any LPM states, simply don't set a LPM policy such that all the HIPM/DIPM probing/enabling will be skipped. Not enabling HIPM or DIPM in the first place is safer than relying on the device following the AHCI specification and respecting the NAK. (There are comments in the code that some devices misbehave when receiving a NAK.) Performing this check in ahci_update_initial_lpm_policy() also has the advantage that a HBA that doesn't support any LPM states will take the exact same code paths as a port that is external/hot plug capable. Side note: the port in ata_port_dbg() has not been given a unique id yet, but this is not overly important as the debug print is disabled unless explicitly enabled using dynamic debug. A follow-up series will make sure that the unique id assignment will be done earlier. For now, the important thing is that the function returns before setting the LPM policy. Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Cc: stable(a)vger.kernel.org Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- Changes since v1: Add debug print as suggested by Mika. drivers/ata/ahci.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 07d66d2c5f0d..5eb38fbbbecd 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1735,6 +1735,14 @@ static void ahci_update_initial_lpm_policy(struct ata_port *ap) if (ap->pflags & ATA_PFLAG_EXTERNAL) return; + /* If no LPM states are supported by the HBA, do not bother with LPM */ + if ((ap->host->flags & ATA_HOST_NO_PART) && + (ap->host->flags & ATA_HOST_NO_SSC) && + (ap->host->flags & ATA_HOST_NO_DEVSLP)) { + ata_port_dbg(ap, "no LPM states supported, not enabling LPM\n"); + return; + } + /* user modified policy via module param */ if (mobile_lpm_policy != -1) { policy = mobile_lpm_policy; -- 2.45.2

6 months, 3 weeks

4
5
0 0

[PATCH v2] riscv: dts: starfive: Set EMMC vqmmc maximum voltage to 3.3V on JH7110 boards

by Shengyu Qu

Currently, for JH7110 boards with EMMC slot, vqmmc voltage for EMMC is fixed to 1.8V, while the spec needs it to be 3.3V on low speed mode and should support switching to 1.8V when using higher speed mode. Since there are no other peripherals using the same voltage source of EMMC's vqmmc(ALDO4) on every board currently supported by mainline kernel, regulator-max-microvolt of ALDO4 should be set to 3.3V. Cc: stable(a)vger.kernel.org Signed-off-by: Shengyu Qu <wiagn233(a)outlook.com> Fixes: 7dafcfa79cc9 ("riscv: dts: starfive: enable DCDC1&ALDO4 node in axp15060") --- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi index 37b4c294ffcc..c7a549ec7452 100644 --- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi +++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi @@ -244,7 +244,7 @@ emmc_vdd: aldo4 { regulator-boot-on; regulator-always-on; regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; regulator-name = "emmc_vdd"; }; }; -- 2.39.2

6 months, 3 weeks

2
4
0 0

[PATCH v6] usb: dwc3: core: Workaround for CSR read timeout

by joswang

From: Jos Wang <joswang(a)lenovo.com> This is a workaround for STAR 4846132, which only affects DWC_usb31 version2.00a operating in host mode. There is a problem in DWC_usb31 version 2.00a operating in host mode that would cause a CSR read timeout When CSR read coincides with RAM Clock Gating Entry. By disable Clock Gating, sacrificing power consumption for normal operation. Cc: stable(a)vger.kernel.org Signed-off-by: Jos Wang <joswang(a)lenovo.com> --- v5 -> v6: no change v4 -> v5: no change v3 -> v4: modify commit message, add Cc: stable(a)vger.kernel.org v2 -> v3: - code refactor - modify comment, add STAR number, workaround applied in host mode - modify commit message, add STAR number, workaround applied in host mode - modify Author Jos Wang v1 -> v2: no change drivers/usb/dwc3/core.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 7ee61a89520b..2a3adc80fe0f 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -957,12 +957,16 @@ static bool dwc3_core_is_valid(struct dwc3 *dwc) static void dwc3_core_setup_global_control(struct dwc3 *dwc) { + unsigned int power_opt; + unsigned int hw_mode; u32 reg; reg = dwc3_readl(dwc->regs, DWC3_GCTL); reg &= ~DWC3_GCTL_SCALEDOWN_MASK; + hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0); + power_opt = DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1); - switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) { + switch (power_opt) { case DWC3_GHWPARAMS1_EN_PWROPT_CLK: /** * WORKAROUND: DWC3 revisions between 2.10a and 2.50a have an @@ -995,6 +999,20 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc) break; } + /* + * This is a workaround for STAR#4846132, which only affects + * DWC_usb31 version2.00a operating in host mode. + * + * There is a problem in DWC_usb31 version 2.00a operating + * in host mode that would cause a CSR read timeout When CSR + * read coincides with RAM Clock Gating Entry. By disable + * Clock Gating, sacrificing power consumption for normal + * operation. + */ + if (power_opt != DWC3_GHWPARAMS1_EN_PWROPT_NO && + hw_mode != DWC3_GHWPARAMS0_MODE_GADGET && DWC3_VER_IS(DWC31, 200A)) + reg |= DWC3_GCTL_DSBLCLKGTNG; + /* check if current dwc3 is on simulation board */ if (dwc->hwparams.hwparams6 & DWC3_GHWPARAMS6_EN_FPGA) { dev_info(dwc->dev, "Running with FPGA optimizations\n"); -- 2.17.1

6 months, 3 weeks

2
2
0 0

Re: Patch "ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()" has been added to the 6.9-stable tree

by Baokun Li

Hi Sasha, Thanks for adapting this patch to the stable branch. Just one nit. On 2024/6/16 10:05, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() > > to the 6.9-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > ext4-fix-slab-out-of-bounds-in-ext4_mb_find_good_gro.patch > and it can be found in the queue-6.9 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 84cee2d2394a43766dd2990edac8a4a05817ef7b > Author: Baokun Li <libaokun1(a)huawei.com> > Date: Tue Mar 19 19:33:20 2024 +0800 > > ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() > > [ Upstream commit 13df4d44a3aaabe61cd01d277b6ee23ead2a5206 ] > > We can trigger a slab-out-of-bounds with the following commands: > > mkfs.ext4 -F /dev/$disk 10G > mount /dev/$disk /tmp/test > echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc > echo test > /tmp/test/file && sync > > ================================================================== > BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] > Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 > CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 > Call Trace: > dump_stack_lvl+0x2c/0x50 > kasan_report+0xb6/0xf0 > ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] > ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] > ext4_mb_new_blocks+0x88a/0x1370 [ext4] > ext4_ext_map_blocks+0x14f7/0x2390 [ext4] > ext4_map_blocks+0x569/0xea0 [ext4] > ext4_do_writepages+0x10f6/0x1bc0 [ext4] > [...] > ================================================================== > > The flow of issue triggering is as follows: > > // Set s_mb_group_prealloc to 2147483647 via sysfs > ext4_mb_new_blocks > ext4_mb_normalize_request > ext4_mb_normalize_group_request > ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc > ext4_mb_regular_allocator > ext4_mb_choose_next_group > ext4_mb_choose_next_group_best_avail > mb_avg_fragment_size_order > order = fls(len) - 2 = 29 > ext4_mb_find_good_group_avg_frag_lists > frag_list = &sbi->s_mb_avg_fragment_size[order] > if (list_empty(frag_list)) // Trigger SOOB! > > At 4k block size, the length of the s_mb_avg_fragment_size list is 14, > but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds > to be triggered by an attempt to access an element at index 29. > > Add a new attr_id attr_clusters_in_group with values in the range > [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as > that type to fix the issue. In addition avoid returning an order > from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) > and reduce some useless loops. > > Fixes: 7e170922f06b ("ext4: Add allocation criteria 1.5 (CR1_5)") > CC: stable(a)vger.kernel.org > Signed-off-by: Baokun Li <libaokun1(a)huawei.com> > Reviewed-by: Jan Kara <jack(a)suse.cz> > Reviewed-by: Ojaswin Mujoo <ojaswin(a)linux.ibm.com> > Link: https://lore.kernel.org/r/20240319113325.3110393-5-libaokun1@huawei.com > Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > index 714f83632e3f9..66b5a68b0254e 100644 > --- a/fs/ext4/mballoc.c > +++ b/fs/ext4/mballoc.c > @@ -831,6 +831,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) > return 0; > if (order == MB_NUM_ORDERS(sb)) > order--; > + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) > + order = MB_NUM_ORDERS(sb) - 1; > return order; > } > > @@ -1008,6 +1010,8 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context > * goal length. > */ > order = fls(ac->ac_g_ex.fe_len) - 1; > + if (WARN_ON_ONCE(order - 1 > MB_NUM_ORDERS(ac->ac_sb))) > + order = MB_NUM_ORDERS(ac->ac_sb); > min_order = order - sbi->s_mb_best_avail_max_trim_order; > if (min_order < 0) > min_order = 0; > diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c > index 295ea9a32de91..ca66e33f61815 100644 > --- a/fs/ext4/sysfs.c > +++ b/fs/ext4/sysfs.c > @@ -29,6 +29,7 @@ typedef enum { > attr_trigger_test_error, > attr_first_error_time, > attr_last_error_time, > + attr_clusters_in_group, > attr_feature, > attr_pointer_ui, > attr_pointer_ul, > @@ -207,13 +208,14 @@ EXT4_ATTR_FUNC(sra_exceeded_retry_limit, 0444); > > EXT4_ATTR_OFFSET(inode_readahead_blks, 0644, inode_readahead, > ext4_sb_info, s_inode_readahead_blks); > +EXT4_ATTR_OFFSET(mb_group_prealloc, 0644, clusters_in_group, > + ext4_sb_info, s_mb_group_prealloc); > EXT4_RW_ATTR_SBI_UI(inode_goal, s_inode_goal); > EXT4_RW_ATTR_SBI_UI(mb_stats, s_mb_stats); > EXT4_RW_ATTR_SBI_UI(mb_max_to_scan, s_mb_max_to_scan); > EXT4_RW_ATTR_SBI_UI(mb_min_to_scan, s_mb_min_to_scan); > EXT4_RW_ATTR_SBI_UI(mb_order2_req, s_mb_order2_reqs); > EXT4_RW_ATTR_SBI_UI(mb_stream_req, s_mb_stream_request); > -EXT4_RW_ATTR_SBI_UI(mb_group_prealloc, s_mb_group_prealloc); > EXT4_RW_ATTR_SBI_UI(mb_max_linear_groups, s_mb_max_linear_groups); > EXT4_RW_ATTR_SBI_UI(extent_max_zeroout_kb, s_extent_max_zeroout_kb); > EXT4_ATTR(trigger_fs_error, 0200, trigger_test_error); > @@ -376,6 +378,7 @@ static ssize_t ext4_generic_attr_show(struct ext4_attr *a, > > switch (a->attr_id) { > case attr_inode_readahead: > + case attr_clusters_in_group: > case attr_pointer_ui: > if (a->attr_ptr == ptr_ext4_super_block_offset) > return sysfs_emit(buf, "%u\n", le32_to_cpup(ptr)); > @@ -459,6 +462,14 @@ static ssize_t ext4_attr_store(struct kobject *kobj, > else > *((unsigned int *) ptr) = t; > return len; > + case attr_clusters_in_group: Since commit f536808adcc3 "ext4: refactor out ext4_generic_attr_store()" is not backported to stable, the following judgement needs to be added here: if (!ptr) return 0; The patch for the 6.6-stable tree has the same problem. Regards, Baokun > + ret = kstrtouint(skip_spaces(buf), 0, &t); > + if (ret) > + return ret; > + if (t > sbi->s_clusters_per_group) > + return -EINVAL; > + *((unsigned int *) ptr) = t; > + return len; > case attr_pointer_ul: > if (!ptr) > return 0;

6 months, 3 weeks

2
2
0 0

[PATCH v2] xhci: Apply XHCI_RESET_TO_DEFAULT quirk to TGL

by Reka Norman

TGL systems have the same issue as ADL, where a large boot firmware delay is seen if USB ports are left in U3 at shutdown. So apply the XHCI_RESET_TO_DEFAULT quirk to TGL as well. The issue it fixes is a ~20s boot time delay when booting from S5. It affects TGL devices, and TGL support was added starting from v5.3. Cc: stable(a)vger.kernel.org Signed-off-by: Reka Norman <rekanorman(a)chromium.org> --- Changes in v2: - Add cc stable drivers/usb/host/xhci-pci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index c040d816e626..137bd3da1128 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -49,6 +49,7 @@ #define PCI_DEVICE_ID_INTEL_DENVERTON_XHCI 0x19d0 #define PCI_DEVICE_ID_INTEL_ICE_LAKE_XHCI 0x8a13 #define PCI_DEVICE_ID_INTEL_TIGER_LAKE_XHCI 0x9a13 +#define PCI_DEVICE_ID_INTEL_TIGER_LAKE_PCH_XHCI 0xa0ed #define PCI_DEVICE_ID_INTEL_COMET_LAKE_XHCI 0xa3af #define PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI 0x51ed #define PCI_DEVICE_ID_INTEL_ALDER_LAKE_N_PCH_XHCI 0x54ed @@ -372,7 +373,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci->quirks |= XHCI_MISSING_CAS; if (pdev->vendor == PCI_VENDOR_ID_INTEL && - (pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI || + (pdev->device == PCI_DEVICE_ID_INTEL_TIGER_LAKE_PCH_XHCI || + pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI || pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_N_PCH_XHCI)) xhci->quirks |= XHCI_RESET_TO_DEFAULT; -- 2.45.2.627.g7a2c4fd464-goog

6 months, 3 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024