| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAKfTPtB7UvUG3C_xiHL-V6eDfDOAkpzFWa0_QQeeRAQG7PovXQ@mail.gmail.com>
Date: Tue, 25 Jan 2022 10:14:41 +0100
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Daniel Jordan <daniel.m.jordan@...cle.com>
Cc: Tadeusz Struk <tadeusz.struk@...aro.org>, peterz@...radead.org,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Zhang Qiao <zhangqiao22@...wei.com>, stable@...r.kernel.org,
linux-kernel@...r.kernel.org,
syzbot+af7a719bc92395ee41b3@...kaller.appspotmail.com
Subject: Re: [PATCH v2] sched/fair: Fix fault in reweight_entity
On Tue, 25 Jan 2022 at 02:18, Daniel Jordan <daniel.m.jordan@...cle.com> wrote:
>
> Hi,
>
> On Thu, Jan 20, 2022 at 12:01:39PM -0800, Tadeusz Struk wrote:
> > Syzbot found a GPF in reweight_entity(). This has been bisected to commit
> > 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group")
> >
> > There is a race between sched_post_fork() and setpriority(PRIO_PGRP)
> > within a thread group that causes a null-ptr-deref in reweight_entity()
> > in CFS. The scenario is that the main process spawns number of new
> > threads, which then call setpriority(PRIO_PGRP, 0, prio), wait, and exit.
> > For each of the new threads the copy_process() gets invoked, which adds
> > the new task_struct to the group, and eventually calls sched_post_fork() for it.
> >
> > In the above scenario there is a possibility that setpriority(PRIO_PGRP)
> > and set_one_prio() will be called for a thread in the group that is just
> > being created by copy_process(), and for which the sched_post_fork() has
> > not been executed yet. This will trigger a null pointer dereference in
> > reweight_entity(), as it will try to access the run queue pointer, which
> > hasn't been set.
>
> It's kinda strange that p->se.cfs_rq is NULLed in __sched_fork().
> AFAICT, that lets set_task_rq_fair() distinguish between fork and other
> paths per ad936d8658fd, but it's causing this problem now and it's not
> the only way that set_task_rq_fair() could tell the difference.
>
> We might be able to get rid of the NULL assignment instead of adding
> code to detect it. Maybe something like this, against today's mainline?
> set_task_rq_fair() would rely on TASK_NEW instead of NULL.
>
> Haven't thought it all the way through, so could be missing something.
> Will think more
Could we use :
set_load_weight(p, !(p->__state & TASK_NEW));
instead of
set_load_weight(p, true);
in set_user_nice and __setscheduler_params.
The current always true value forces the update of the weight of the
cfs_rq of the task which is not already set in this case
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 848eaa0efe0ea..9a5b264c5dc10 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4241,10 +4241,6 @@ static void __sched_fork(unsigned long clone_flags, struct task_struct *p)
> p->se.vruntime = 0;
> INIT_LIST_HEAD(&p->se.group_node);
>
> -#ifdef CONFIG_FAIR_GROUP_SCHED
> - p->se.cfs_rq = NULL;
> -#endif
> -
> #ifdef CONFIG_SCHEDSTATS
> /* Even if schedstat is disabled, there should not be garbage */
> memset(&p->stats, 0, sizeof(p->stats));
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 5146163bfabb9..7aff3b603220d 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3339,15 +3339,19 @@ static inline void update_tg_load_avg(struct cfs_rq *cfs_rq)
> * caller only guarantees p->pi_lock is held; no other assumptions,
> * including the state of rq->lock, should be made.
> */
> -void set_task_rq_fair(struct sched_entity *se,
> - struct cfs_rq *prev, struct cfs_rq *next)
> +void set_task_rq_fair(struct task_struct *p, struct cfs_rq *next)
> {
> + struct sched_entity *se = &p->se;
> + struct cfs_rq *prev = se->cfs_rq;
> u64 p_last_update_time;
> u64 n_last_update_time;
>
> if (!sched_feat(ATTACH_AGE_LOAD))
> return;
>
> + if (p->__state == TASK_NEW)
> + return;
> +
> /*
> * We are supposed to update the task to "current" time, then its up to
> * date and ready to go to new CPU/cfs_rq. But we have difficulty in
> @@ -3355,7 +3359,7 @@ void set_task_rq_fair(struct sched_entity *se,
> * time. This will result in the wakee task is less decayed, but giving
> * the wakee more load sounds not bad.
> */
> - if (!(se->avg.last_update_time && prev))
> + if (!se->avg.last_update_time)
> return;
>
> #ifndef CONFIG_64BIT
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index de53be9057390..a6f749f136ee1 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -514,11 +514,10 @@ extern int sched_group_set_shares(struct task_group *tg, unsigned long shares);
> extern int sched_group_set_idle(struct task_group *tg, long idle);
>
> #ifdef CONFIG_SMP
> -extern void set_task_rq_fair(struct sched_entity *se,
> - struct cfs_rq *prev, struct cfs_rq *next);
> +extern void set_task_rq_fair(struct task_struct *p, struct cfs_rq *next);
> #else /* !CONFIG_SMP */
> -static inline void set_task_rq_fair(struct sched_entity *se,
> - struct cfs_rq *prev, struct cfs_rq *next) { }
> +static inline void set_task_rq_fair(struct task_struct *p,
> + struct cfs_rq *next) {}
> #endif /* CONFIG_SMP */
> #endif /* CONFIG_FAIR_GROUP_SCHED */
>
> @@ -1910,7 +1909,7 @@ static inline void set_task_rq(struct task_struct *p, unsigned int cpu)
> #endif
>
> #ifdef CONFIG_FAIR_GROUP_SCHED
> - set_task_rq_fair(&p->se, p->se.cfs_rq, tg->cfs_rq[cpu]);
> + set_task_rq_fair(p, tg->cfs_rq[cpu]);
> p->se.cfs_rq = tg->cfs_rq[cpu];
> p->se.parent = tg->se[cpu];
> #endif
Powered by blists - more mailing lists