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

[PATCH] sched/fair: Fix ksmd and kthreadd running on isolated CPU0 on arm64 systems

by wujing

This bug can be reproduced on Kunpeng arm64 and Phytium arm physical machines, as well as in virtual machine environments, based on the linux-4.19.y stable branch: 1. Check the number of CPUs on the system: nproc --all 96 2. Add the parameter isolcpus=0-85 to the grub configuration, update grub, and reboot. 3. Check the ksmd process: ps aux | grep -i ksmd root 502 0.0 0.0 0 0 ? S 10:00 0:00 [ksmd] ps -o pid,psr,comm -p 502 PID PSR COMMAND 502 0 ksmd 4. Check the kthreadd process: ps aux | grep -i kthreadd root 2 0.0 0.0 0 0 ? S 10:00 0:00 [kthreadd] ps -o pid,psr,comm -p 2 PID PSR COMMAND 2 0 kthreadd From the output above, it can be seen that both ksmd and kthreadd are still running on CPU0, which is unreasonable since CPU0 has been isolated. Cc: stable(a)vger.kernel.org # 4.19.x Signed-off-by: wujing <realwujing(a)qq.com> Signed-off-by: QiLiang Yuan <yuanql9(a)chinatelecom.cn> --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 0950cabfc1d0..454021ff70a1 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6211,7 +6211,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc)); if (!this_sd) - return -1; + return housekeeping_any_cpu(HK_FLAG_DOMAIN); /* * Due to large variance we need a large fuzz factor; hackbench in -- 2.39.5

10 months, 2 weeks

2
1
0 0

[PATCH] sched/fair: Correct CPU selection from isolated domain

by wujing

From: wujing <realwujing(a)gmail.com> We encountered an issue where the kernel thread `ksmd` runs on the PMD dedicated isolated core, leading to high latency in OVS packets. Upon analysis, we discovered that this is caused by the current select_idle_smt() function not taking the sched_domain mask into account. Kernel version: linux-4.19.y Cc: stable(a)vger.kernel.org # 4.19.x Signed-off-by: wujing <realwujing(a)qq.com> Signed-off-by: QiLiang Yuan <yuanql9(a)chinatelecom.cn> --- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 09f82c84474b..0950cabfc1d0 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6171,7 +6171,8 @@ static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int t return -1; for_each_cpu(cpu, cpu_smt_mask(target)) { - if (!cpumask_test_cpu(cpu, &p->cpus_allowed)) + if (!cpumask_test_cpu(cpu, &p->cpus_allowed) || + !cpumask_test_cpu(cpu, sched_domain_span(sd))) continue; if (available_idle_cpu(cpu)) return cpu; -- 2.39.5

10 months, 2 weeks

2
1
0 0

[PATCH] sched/fair: Fix ksmd and kthreadd running on isolated CPU0 on arm64 systems

by wujing

This bug can be reproduced on Kunpeng arm64 and Phytium arm physical machines, as well as in virtual machine environments, based on the linux-4.19.y stable branch: 1. Check the number of CPUs on the system: nproc --all 96 2. Add the parameter isolcpus=0-85 to the grub configuration, update grub, and reboot. 3. Check the ksmd process: ps aux | grep -i ksmd root 502 0.0 0.0 0 0 ? S 10:00 0:00 [ksmd] ps -o pid,psr,comm -p 502 PID PSR COMMAND 502 0 ksmd 4. Check the kthreadd process: ps aux | grep -i kthreadd root 2 0.0 0.0 0 0 ? S 10:00 0:00 [kthreadd] ps -o pid,psr,comm -p 2 PID PSR COMMAND 2 0 kthreadd From the output above, it can be seen that both ksmd and kthreadd are still running on CPU0, which is unreasonable since CPU0 has been isolated. Signed-off-by: wujing <realwujing(a)qq.com> Signed-off-by: QiLiang Yuan <yuanql9(a)chinatelecom.cn> --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 0950cabfc1d0..454021ff70a1 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6211,7 +6211,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc)); if (!this_sd) - return -1; + return housekeeping_any_cpu(HK_FLAG_DOMAIN); /* * Due to large variance we need a large fuzz factor; hackbench in -- 2.39.5

10 months, 2 weeks

3
4
0 0

[PATCH v2] [ARM] fix reference leak in locomo_init_one_child()

by Ma Ke

Once device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. device_register() includes device_add(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch as suggestions. --- arch/arm/common/locomo.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c index 309b74783468..9e48cbb2568e 100644 --- a/arch/arm/common/locomo.c +++ b/arch/arm/common/locomo.c @@ -253,6 +253,8 @@ locomo_init_one_child(struct locomo *lchip, struct locomo_dev_info *info) ret = device_register(&dev->dev); if (ret) { + put_device(&dev->dev); + return ret; out: kfree(dev); } -- 2.25.1

10 months, 2 weeks

2
1
0 0

[PATCH] usb: chipidea: ci_hdrc_imx: decrement device's refcount on the error path of .probe()

by Joe Hattori

Current implementation of ci_hdrc_imx_probe() does not decrement the refcount of the device obtained in usbmisc_get_init_data(). Add a put_device() call before returning an error after the call. This bug was found by an experimental static analysis tool that I am developing. Cc: stable(a)vger.kernel.org Fixes: f40017e0f332 ("chipidea: usbmisc_imx: Add USB support for VF610 SoCs") Signed-off-by: Joe Hattori <joe(a)pf.is.s.u-tokyo.ac.jp> --- drivers/usb/chipidea/ci_hdrc_imx.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index f2801700be8e..6418052264f2 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -370,25 +370,29 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) data->pinctrl = devm_pinctrl_get(dev); if (PTR_ERR(data->pinctrl) == -ENODEV) data->pinctrl = NULL; - else if (IS_ERR(data->pinctrl)) - return dev_err_probe(dev, PTR_ERR(data->pinctrl), + else if (IS_ERR(data->pinctrl)) { + ret = dev_err_probe(dev, PTR_ERR(data->pinctrl), "pinctrl get failed\n"); + goto err_put; + } data->hsic_pad_regulator = devm_regulator_get_optional(dev, "hsic"); if (PTR_ERR(data->hsic_pad_regulator) == -ENODEV) { /* no pad regulator is needed */ data->hsic_pad_regulator = NULL; - } else if (IS_ERR(data->hsic_pad_regulator)) - return dev_err_probe(dev, PTR_ERR(data->hsic_pad_regulator), + } else if (IS_ERR(data->hsic_pad_regulator)) { + ret = dev_err_probe(dev, PTR_ERR(data->hsic_pad_regulator), "Get HSIC pad regulator error\n"); + goto err_put; + } if (data->hsic_pad_regulator) { ret = regulator_enable(data->hsic_pad_regulator); if (ret) { dev_err(dev, "Failed to enable HSIC pad regulator\n"); - return ret; + goto err_put; } } } @@ -402,13 +406,14 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) dev_err(dev, "pinctrl_hsic_idle lookup failed, err=%ld\n", PTR_ERR(pinctrl_hsic_idle)); - return PTR_ERR(pinctrl_hsic_idle); + ret = PTR_ERR(pinctrl_hsic_idle); + goto err_put; } ret = pinctrl_select_state(data->pinctrl, pinctrl_hsic_idle); if (ret) { dev_err(dev, "hsic_idle select failed, err=%d\n", ret); - return ret; + goto err_put; } data->pinctrl_hsic_active = pinctrl_lookup_state(data->pinctrl, @@ -417,7 +422,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) dev_err(dev, "pinctrl_hsic_active lookup failed, err=%ld\n", PTR_ERR(data->pinctrl_hsic_active)); - return PTR_ERR(data->pinctrl_hsic_active); + ret = PTR_ERR(data->pinctrl_hsic_active); + goto err_put; } } @@ -527,6 +533,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) if (pdata.flags & CI_HDRC_PMQOS) cpu_latency_qos_remove_request(&data->pm_qos_req); data->ci_pdev = NULL; +err_put: + put_device(data->usbmisc_data->dev); return ret; } -- 2.34.1

10 months, 2 weeks

3
3
0 0

[PATCH 2/3] vfs: Fix implicit conversion problem when testing overflow case

by Julian Sun

The overflow check in generic_copy_file_checks() and generic_remap_checks() is now broken because the result of the addition is implicitly converted to an unsigned type, which disrupts the comparison with signed numbers. This caused the kernel to not return EOVERFLOW in copy_file_range() call with len is set to 0xffffffffa003e45bul. Use the check_add_overflow() macro to fix this issue. Reported-and-tested-by: syzbot+296b1c84b9cbf306e5a0(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=296b1c84b9cbf306e5a0 Fixes: 1383a7ed6749 ("vfs: check file ranges before cloning files") Fixes: 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") Inspired-by: Dave Chinner <david(a)fromorbit.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Julian Sun <sunjunchao2870(a)gmail.com> --- fs/read_write.c | 5 +++-- fs/remap_range.c | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index 070a7c33b9dd..5211246edc2e 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -1509,7 +1509,7 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in, struct inode *inode_in = file_inode(file_in); struct inode *inode_out = file_inode(file_out); uint64_t count = *req_count; - loff_t size_in; + loff_t size_in, tmp; int ret; ret = generic_file_rw_checks(file_in, file_out); @@ -1544,7 +1544,8 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in, return -ETXTBSY; /* Ensure offsets don't wrap. */ - if (pos_in + count < pos_in || pos_out + count < pos_out) + if (check_add_overflow(pos_in, count, &tmp) || + check_add_overflow(pos_out, count, &tmp)) return -EOVERFLOW; /* Shorten the copy to EOF */ diff --git a/fs/remap_range.c b/fs/remap_range.c index 28246dfc8485..6fdeb3c8cb70 100644 --- a/fs/remap_range.c +++ b/fs/remap_range.c @@ -36,7 +36,7 @@ static int generic_remap_checks(struct file *file_in, loff_t pos_in, struct inode *inode_out = file_out->f_mapping->host; uint64_t count = *req_count; uint64_t bcount; - loff_t size_in, size_out; + loff_t size_in, size_out, tmp; loff_t bs = inode_out->i_sb->s_blocksize; int ret; @@ -45,7 +45,8 @@ static int generic_remap_checks(struct file *file_in, loff_t pos_in, return -EINVAL; /* Ensure offsets don't wrap. */ - if (pos_in + count < pos_in || pos_out + count < pos_out) + if (check_add_overflow(pos_in, count, &tmp) || + check_add_overflow(pos_out, count, &tmp)) return -EINVAL; size_in = i_size_read(inode_in); -- 2.39.2

10 months, 2 weeks

5
7
0 0

[PATCH 6.1.y] i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition

by jianqi.ren.cn＠windriver.com

From: Kaixin Wang <kxwang23(a)m.fudan.edu.cn> [ Upstream commit 609366e7a06d035990df78f1562291c3bf0d4a12 ] In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove. Signed-off-by: Kaixin Wang <kxwang23(a)m.fudan.edu.cn> Link: https://lore.kernel.org/r/20240911153544.848398-1-kxwang23@m.fudan.edu.cn Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> --- drivers/i3c/master/i3c-master-cdns.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c index 35b90bb686ad..c5a37f58079a 100644 --- a/drivers/i3c/master/i3c-master-cdns.c +++ b/drivers/i3c/master/i3c-master-cdns.c @@ -1667,6 +1667,7 @@ static int cdns_i3c_master_remove(struct platform_device *pdev) { struct cdns_i3c_master *master = platform_get_drvdata(pdev); + cancel_work_sync(&master->hj_work); i3c_master_unregister(&master->base); clk_disable_unprepare(master->sysclk); -- 2.25.1

10 months, 2 weeks

2
1
0 0

[PATCH] Input: Fix error handling in input_register_device()

by Ma Ke

When device_add(&dev->dev) failed, calling put_device() to explicitly release dev->dev. Otherwise, it could cause double free problem. As comment of device_add() says, if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 0cd587735205 ("Input: preallocate memory to hold event values") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/input/input.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/input/input.c b/drivers/input/input.c index 7f0477e04ad2..a0a36aa90ecc 100644 --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -2456,8 +2456,10 @@ int input_register_device(struct input_dev *dev) input_dev_poller_finalize(dev->poller); error = device_add(&dev->dev); - if (error) + if (error) { + put_device(&dev->dev); goto err_devres_free; + } path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL); pr_info("%s as %s\n", -- 2.25.1

10 months, 2 weeks

2
1
0 0

[PATCH] hugetlb: fix NULL pointer dereference in trace_hugetlbfs_alloc_inode

by Muchun Song

hugetlb_file_setup() will pass a NULL @dir to hugetlbfs_get_inode(), so we will access a NULL pointer for @dir. Fix it and set __entry->dr to 0 if @dir is NULL. Because ->i_ino cannot be 0 (see get_next_ino()), there is no confusing if user sees a 0 inode number. Fixes: 318580ad7f28 ("hugetlbfs: support tracepoint") Cc: stable(a)vger.kernel.org Reported-by: Cheung Wall <zzqq0103.hey(a)gmail.com> Closes: https://lore.kernel.org/linux-mm/02858D60-43C1-4863-A84F-3C76A8AF1F15@linux… Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> --- include/trace/events/hugetlbfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/trace/events/hugetlbfs.h b/include/trace/events/hugetlbfs.h index 8331c904a9ba8..59605dfaeeb43 100644 --- a/include/trace/events/hugetlbfs.h +++ b/include/trace/events/hugetlbfs.h @@ -23,7 +23,7 @@ TRACE_EVENT(hugetlbfs_alloc_inode, TP_fast_assign( __entry->dev = inode->i_sb->s_dev; __entry->ino = inode->i_ino; - __entry->dir = dir->i_ino; + __entry->dir = dir ? dir->i_ino : 0; __entry->mode = mode; ), -- 2.20.1

10 months, 2 weeks

2
1
0 0

[REGRESSION] amdgpu: thinkpad e495 backlight brightness resets after suspend

by Siva Mahadevan

#regzbot introduced: 99a02eab8 Observed behaviour: linux-stable v6.12.5 has a regression on my thinkpad e495 where suspend/resume of the laptop results in my backlight brightness settings to be reset to some very high value. After resume, I'm able to increase brightness further until max brightness, but I'm not able to decrease it anymore. Behaviour prior to regression: linux-stable v6.12.4 correctly maintains the same brightness setting on the backlight that was set prior to suspend/resume. Notes: I bisected this issue between v6.12.4 and v6.12.5 to commit 99a02eab8 titled "drm/amdgpu: rework resume handling for display (v2)". Hardware: * lenovo thinkpad e495 * AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx * VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series] (rev c2)

10 months, 2 weeks

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror