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
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
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
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
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
#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)
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: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface")
Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
---
drivers/pci/probe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 2e81ab0f5a25..73464ffbb0fc 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -974,8 +974,10 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge)
name = dev_name(&bus->dev);
err = device_register(&bus->dev);
- if (err)
+ if (err) {
+ put_device(&bus->dev);
goto unregister;
+ }
pcibios_add_bus(bus);
--
2.25.1