mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Zecheng Li <zecheng@google.com>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Josh Don <joshdon@google.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched/fair: Fix potential memory corruption in child_cfs_rq_on_list
Date: Wed, 5 Mar 2025 09:24:34 +0530	[thread overview]
Message-ID: <6409142e-d535-4ddd-b58d-41ea793f61b4@amd.com> (raw)
In-Reply-To: <20250304214031.2882646-1-zecheng@google.com>

Hello Li,

On 3/5/2025 3:10 AM, Zecheng Li wrote:
> child_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.
> This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,
> making the conversion invalid and potentially leading to memory
> corruption. Depending on the relative positions of leaf_cfs_rq_list and
> the task group (tg) pointer within the struct, this can cause a memory
> fault or access garbage data.
> 
> The issue arises in list_add_leaf_cfs_rq, where both
> cfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the same
> leaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.
> 
> This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the main
> conditional in child_cfs_rq_on_list. This ensures that the container_of
> operation will convert a correct cfs_rq struct.
> 
> This check is sufficient because only cfs_rqs on the same CPU are added
> to the list, so verifying the 'prev' pointer against the current rq's list
> head is enough.
> 
> Fixes a potential memory corruption issue that due to current struct
> layout might not be manifesting as a crash but could lead to unpredictable
> behavior when the layout changes.
> 
> Signed-off-by: Zecheng Li <zecheng@google.com>
> ---
>   kernel/sched/fair.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 857808da23d8..9dafb374d76d 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4061,15 +4061,17 @@ static inline bool child_cfs_rq_on_list(struct cfs_rq *cfs_rq)
>   {
>   	struct cfs_rq *prev_cfs_rq;
>   	struct list_head *prev;
> +	struct rq *rq = rq_of(cfs_rq);
>   
>   	if (cfs_rq->on_list) {
>   		prev = cfs_rq->leaf_cfs_rq_list.prev;
>   	} else {
> -		struct rq *rq = rq_of(cfs_rq);
> -
>   		prev = rq->tmp_alone_branch;
>   	}

A "SCHED_WARN_ON(prev == &rq->leaf_cfs_rq_list)" here is easily tripped
during early boot on my setup before this fix.

Only nit. is perhaps that return can go into the else clause above since
"cfs_rq->on_list" case will guarantee a "leaf_cfs_rq_list" pointer that
is embedded in a valid cfs_rq struct but I've no strong feelings.

Feel free to add:

Reviewed-and-tested-by: K Prateek Nayak <kprateek.nayak@amd.com>

-- 
Thanks and Regards,
Prateek

>   
> +	if (prev == &rq->leaf_cfs_rq_list)
> +		return false;
> +
>   	prev_cfs_rq = container_of(prev, struct cfs_rq, leaf_cfs_rq_list);
>   
>   	return (prev_cfs_rq->tg->parent == cfs_rq->tg);
> 
> base-commit: 7ab02bd36eb444654183ad6c5b15211ddfa32a8f




  reply	other threads:[~2025-03-05  3:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04 21:40 Zecheng Li
2025-03-05  3:54 ` K Prateek Nayak [this message]
2025-03-05  8:35 ` Vincent Guittot
2025-03-05 16:42 ` [tip: sched/urgent] " tip-bot2 for Zecheng Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6409142e-d535-4ddd-b58d-41ea793f61b4@amd.com \
    --to=kprateek.nayak@amd.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=zecheng@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®