mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2026 -----
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 36 participants
  • 22986 discussions
[PATCH openEuler-1.0-LTS] PCI: Fix pci_slot_trylock() error handling
by Ziming Du 09 Mar '26

09 Mar '26
From: Jinhui Guo <guojinhui.liam(a)bytedance.com> mainline inclusion from mainline-v7.0-rc1 commit 9368d1ee62829b08aa31836b3ca003803caf0b72 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8599 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com] Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251212145528.2555-1-guojinhui.liam@bytedance.com Signed-off-by: Ziming Du <duziming2(a)huawei.com> --- drivers/pci/pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b93605616d4e4..fbef3c37f37fa 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -5144,10 +5144,8 @@ static int pci_slot_trylock(struct pci_slot *slot) if (!dev->slot || dev->slot != slot) continue; if (dev->subordinate) { - if (!pci_bus_trylock(dev->subordinate)) { - pci_dev_unlock(dev); + if (!pci_bus_trylock(dev->subordinate)) goto unlock; - } } else if (!pci_dev_trylock(dev)) goto unlock; } -- 2.43.0
2 1
0 0
[PATCH OLK-5.10] [Backport] sched/rt: Skip currently executing CPU in rto_next_cpu()
by Chen Jinghuang 09 Mar '26

09 Mar '26
mainline inclusion from mainline-v7.0-rc1 commit 94894c9c477e53bcea052e075c53f89df3d2a33e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios. Fixes: 4bdced5c9a29 ("sched/rt: Simplify the IPI based RT balancing logic") Suggested-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Suggested-by: K Prateek Nayak <kprateek.nayak(a)amd.com> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Reviewed-by: Valentin Schneider <vschneid(a)redhat.com> Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- kernel/sched/rt.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index ddbc857a28b8..dbc3a40a68fa 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -2013,6 +2013,7 @@ static void push_rt_tasks(struct rq *rq) */ static int rto_next_cpu(struct root_domain *rd) { + int this_cpu = smp_processor_id(); int next; int cpu; @@ -2036,6 +2037,10 @@ static int rto_next_cpu(struct root_domain *rd) rd->rto_cpu = cpu; + /* Do not send IPI to self */ + if (cpu == this_cpu) + continue; + if (cpu < nr_cpu_ids) return cpu; -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] arm64/mpam: Fix warning of schedule state in resctrl_arch_mon_ctx_alloc()
by Zeng Heng 09 Mar '26

09 Mar '26
hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8686 ------------------ resctrl_arch_mon_ctx_alloc() triggers a scheduling state warning when calling kmalloc() while the task is in a non-running state: do not call blocking ops when !TASK_RUNNING; state=1 set at prepare_to_wait WARNING: CPU: 78 PID: 12592 at kernel/sched/core.c:10584 _might_sleep Call trace: _might_sleep+0x1cc/0xf8 _kmalloc_cache_alloc_node+0x3a0/0x4e0 kmalloc_trace+0x44/0x120 resctrl_arch_mon_ctx_alloc+0xf0/0x178 mon_event_read+0xa0/0x308 mkdir_mondata_subdir+0x24c/0x330 mkdir_mondata_all+0x17c/0x248 rdt_get_tree+0x2e8/0x680 vfs_get_tree+0x5c/0x190 do_new_mount+0x27c/0x408 path_mount+0x2ac/0x448 arm64_sys_mount+0x1d4/0x228 Refactor the call sequence in resctrl_arch_mon_ctx_alloc() and ensure the allocation is performed in TASK_RUNNING state to avoid schedule state corrupted. Fixes: 9119da143939 ("arm_mpam: resctrl: Allow resctrl to allocate monitors") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_resctrl.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 9950cc4eebf4..a33957651732 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -388,32 +388,30 @@ struct rdt_resource *resctrl_arch_get_resource(enum resctrl_res_level l) return &mpam_resctrl_exports[l].resctrl_res; } -static void *resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, - int evtid) +static u32 resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, + int evtid) { - u32 *ret = kmalloc(sizeof(*ret), GFP_KERNEL); - - if (!ret) - return ERR_PTR(-ENOMEM); - - *ret = __mon_is_rmid_idx; - return ret; + return __mon_is_rmid_idx; } void *resctrl_arch_mon_ctx_alloc(struct rdt_resource *r, int evtid) { DEFINE_WAIT(wait); - void *ret; + u32 *ret; + + ret = kmalloc(sizeof(*ret), GFP_KERNEL); + if (!ret) + return ERR_PTR(-ENOMEM); might_sleep(); do { prepare_to_wait(&resctrl_mon_ctx_waiters, &wait, TASK_INTERRUPTIBLE); - ret = resctrl_arch_mon_ctx_alloc_no_wait(r, evtid); - if (PTR_ERR(ret) == -ENOSPC) + *ret = resctrl_arch_mon_ctx_alloc_no_wait(r, evtid); + if (*ret == -ENOSPC) schedule(); - } while (PTR_ERR(ret) == -ENOSPC && !signal_pending(current)); + } while (*ret == -ENOSPC && !signal_pending(current)); finish_wait(&resctrl_mon_ctx_waiters, &wait); return ret; -- 2.25.1
2 1
0 0
[PATCH OLK-6.6 0/2] Fix TLBI broadcast optimization loss and incorrect dvmbm handling
by Tian Zheng 09 Mar '26

09 Mar '26
Fix 1 In the TLBI broadcast-optimization feature, the SYS_LSUDVM_CTRL_EL2 register controls whether the feature is enabled. When LPI low-power mode is enabled, this register is cleared as the pCPU powers down into LPI mode, causing the TLBI broadcast optimization to stop working. The fix saves and restores this control register in the callbacks for entering and exiting LPI mode. Fix 2 The current TLBI broadcast-optimization logic only supports normal VMs. If the feature is enabled globally, VMs that are not yet adapted for it, such as CCA will use an incorrect TLBI broadcast bitmap, which can cause a panic in CCA VMs. The fix moves the actual enable/disable of the dvmbm functionality into the vcpu load and vcpu put functions. Tian Zheng (2): KVM: arm64: Fix TLBI optimization broken in LPI mode KVM: arm64: Fix CCA guest panic when dvmbm is enabled arch/arm64/kvm/arm.c | 6 ++++++ arch/arm64/kvm/hisilicon/hisi_virt.c | 8 +++----- arch/arm64/kvm/hisilicon/hisi_virt.h | 19 +++++++++++++++++++ 3 files changed, 28 insertions(+), 5 deletions(-) -- 2.33.0
1 2
0 0
[PATCH OLK-5.10] SUNRPC: Ensure the transport backchannel association
by Dong Chenchen 09 Mar '26

09 Mar '26
From: Benjamin Coddington <bcodding(a)redhat.com> mainline inclusion from mainline-v5.12-rc6 commit 98b5cee37389b899de044bc4aac56e6ff33dbd4d category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8655 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If the server sends CB_ calls on a connection that is not associated with the backchannel, refuse to process the call and shut down the connection. This avoids a NULL dereference crash in xprt_complete_bc_request(). There's not much more we can do in this situation unless we want to look into allowing all connections to be associated with the fore and back channel. Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/sunrpc/xprtsock.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c index 1ef469ddea89..a6580946ab69 100644 --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -558,6 +558,10 @@ xs_read_stream_call(struct sock_xprt *transport, struct msghdr *msg, int flags) struct rpc_rqst *req; ssize_t ret; + /* Is this transport associated with the backchannel? */ + if (!xprt->bc_serv) + return -ESHUTDOWN; + /* Look up and lock the request corresponding to the given XID */ req = xprt_lookup_bc_request(xprt, transport->recv.xid); if (!req) { -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] [Backport] procfs: fix missing RCU protection when reading real_parent in do_task_stat()
by Chen Jinghuang 09 Mar '26

09 Mar '26
From: Jinliang Zheng <alexjlzheng(a)tencent.com> stable inclusion from stable-v5.10.252 commit fefa0fcd78be465b7ad4c497fa6ec90d64194c04 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8688 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng <alexjlzheng(a)tencent.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Cc: David Hildenbrand <david(a)kernel.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: ruippan <ruippan(a)tencent.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/proc/array.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index d5fed9281863..6bb4c81ba66e 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -510,7 +510,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, } sid = task_session_nr_ns(task, ns); - ppid = task_tgid_nr_ns(task->real_parent, ns); + ppid = task_ppid_nr_ns(task, ns); pgid = task_pgrp_nr_ns(task, ns); unlock_task_sighand(task, &flags); -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] [Backport] procfs: fix missing RCU protection when reading real_parent in do_task_stat()
by Chen Jinghuang 09 Mar '26

09 Mar '26
From: Jinliang Zheng <alexjlzheng(a)tencent.com> stable inclusion from stable-v6.6.128 commit 0e64bd46a04a4fd61279aca9f53a664e9e5f7e7e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8688 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng <alexjlzheng(a)tencent.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Cc: David Hildenbrand <david(a)kernel.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: ruippan <ruippan(a)tencent.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/proc/array.c [Context Conflicts] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 6a4b0a850dce..288f19956e04 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -544,7 +544,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, } sid = task_session_nr_ns(task, ns); - ppid = task_tgid_nr_ns(task->real_parent, ns); + ppid = task_ppid_nr_ns(task, ns); pgid = task_pgrp_nr_ns(task, ns); unlock_task_sighand(task, &flags); -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] [Backport] sched/rt: Skip currently executing CPU in rto_next_cpu()
by Chen Jinghuang 09 Mar '26

09 Mar '26
mainline inclusion from mainline-v7.0-rc1 commit 94894c9c477e53bcea052e075c53f89df3d2a33e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 94894c9c477e53bcea052e075c53f89df3d2a33e ] CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios. Fixes: 4bdced5c9a29 ("sched/rt: Simplify the IPI based RT balancing logic") Suggested-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Suggested-by: K Prateek Nayak <kprateek.nayak(a)amd.com> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Reviewed-by: Valentin Schneider <vschneid(a)redhat.com> Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- kernel/sched/rt.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 549b9ecfda7d..48d53bf0161b 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -2231,6 +2231,7 @@ static void push_rt_tasks(struct rq *rq) */ static int rto_next_cpu(struct root_domain *rd) { + int this_cpu = smp_processor_id(); int next; int cpu; @@ -2254,6 +2255,10 @@ static int rto_next_cpu(struct root_domain *rd) rd->rto_cpu = cpu; + /* Do not send IPI to self */ + if (cpu == this_cpu) + continue; + if (cpu < nr_cpu_ids) return cpu; -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] [Backport] procfs: fix missing RCU protection when reading real_parent in do_task_stat()
by Chen Jinghuang 09 Mar '26

09 Mar '26
From: Jinliang Zheng <alexjlzheng(a)tencent.com> stable inclusion from stable-v6.6.128 commit 0e64bd46a04a4fd61279aca9f53a664e9e5f7e7e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8688 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng <alexjlzheng(a)tencent.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Cc: David Hildenbrand <david(a)kernel.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: ruippan <ruippan(a)tencent.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 6a4b0a850dce..288f19956e04 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -544,7 +544,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, } sid = task_session_nr_ns(task, ns); - ppid = task_tgid_nr_ns(task->real_parent, ns); + ppid = task_ppid_nr_ns(task, ns); pgid = task_pgrp_nr_ns(task, ns); unlock_task_sighand(task, &flags); -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] [Backport] procfs: fix missing RCU protection when reading real_parent in do_task_stat()
by Chen Jinghuang 09 Mar '26

09 Mar '26
From: Jinliang Zheng <alexjlzheng(a)tencent.com> stable inclusion from stable-v6.6.128 commit 0e64bd46a04a4fd61279aca9f53a664e9e5f7e7e category: bugfix bugzilla: AR.SR.IR20250327002298.006.012 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng <alexjlzheng(a)tencent.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Cc: David Hildenbrand <david(a)kernel.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: ruippan <ruippan(a)tencent.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 6a4b0a850dce..288f19956e04 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -544,7 +544,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, } sid = task_session_nr_ns(task, ns); - ppid = task_tgid_nr_ns(task->real_parent, ns); + ppid = task_ppid_nr_ns(task, ns); pgid = task_pgrp_nr_ns(task, ns); unlock_task_sighand(task, &flags); -- 2.34.1
2 1
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • 5
  • ...
  • 2299
  • Older →

HyperKitty Powered by HyperKitty