From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Xia Fukun <xiafukun@huawei.com>
Cc: cve@kernel.org, linux-kernel@vger.kernel.org,
linux-cve-announce@vger.kernel.org,
"Zhangqiao (2012 lab)" <zhangqiao22@huawei.com>,
"Chenhui (Judy)" <judy.chenhui@huawei.com>
Subject: Re: CVE-2022-48921: sched/fair: Fix fault in reweight_entity
Date: Fri, 30 Aug 2024 12:45:55 +0200 [thread overview]
Message-ID: <2024083045-slinky-chatty-d1fa@gregkh> (raw)
In-Reply-To: <2024082539-balancing-rematch-d61d@gregkh>
On Sun, Aug 25, 2024 at 07:54:40AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Aug 24, 2024 at 05:52:05PM +0800, Xia Fukun wrote:
> >
> > On 2024/8/22 11:31, Greg Kroah-Hartman wrote:
> > > Description
> > > ===========
> > >
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > sched/fair: Fix fault in reweight_entity
> > >
> > > 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, -20),
> > > wait, and exit. For each of the new threads the copy_process() gets
> > > invoked, which adds the new task_struct and calls sched_post_fork()
> > > for it.
> > >
> > >
> > > The Linux kernel CVE team has assigned CVE-2022-48921 to this issue.
> > >
> >
> > Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity")
> > is reverted by commit b1e8206582f9 ("sched: Fix yet more sched_fork()
> > races"). Since commit 13765de8148f only fixes a single instance
> > of this problem, not the whole class.
> >
> > I think the CVE-2022-48921 needs to adjust the corresponding commit
> > to commit b1e8206582f9 ("sched: Fix yet more sched_fork() races").
>
> I think we just need to assign a new CVE to b1e8206582f9, as that was
> not backported to everywhere that 13765de8148f was applied, right?
> Wouldn't that be the correct thing to do as it did fix things in a
> different way.
CVE-2022-48944 is now assigned for this, thanks.
greg k-h
prev parent reply other threads:[~2024-08-30 10:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 3:31 CVE-2022-48921: sched/fair: Fix fault in reweight_entity Greg Kroah-Hartman
2024-08-24 9:52 ` Xia Fukun
2024-08-25 5:54 ` Greg Kroah-Hartman
2024-08-30 10:45 ` Greg Kroah-Hartman [this message]
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=2024083045-slinky-chatty-d1fa@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=judy.chenhui@huawei.com \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xiafukun@huawei.com \
--cc=zhangqiao22@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.