NACK: [Xenial][SRU][CVE-2018-20784][PATCH 0/1] fix infinite loop
Gavin Guo
gavin.guo at canonical.com
Sat Oct 26 09:09:11 UTC 2019
Hi Connor/Tyler,
Thank you for notifying me and we just had a case related the
CVE 2018-20784.
I reviewed the patch set and found v4.15 also reverts the patch
a9e7f6544b9c:
cf740dd81381 sched/fair: Fix infinite loop in update_blocked_averages() by
reverting a9e7f6544b9c
$ git describe --contains cf740dd81381
Ubuntu-4.15.0-59.66~3542
and didn't include the ones just backported for Xenial:
v5.1-rc2:
039ae8bcf7a5 sched/fair: Fix O(nr_cgroups) in the load balancing path
31bc6aeaab1d sched/fair: Optimize update_blocked_averages()
f6783319737f sched/fair: Fix insertion in rq->leaf_cfs_rq_list
5d299eabea5a sched/fair: Add tmp_alone_branch assertion
So, that means the regression of LP 1747896 is happening on the v4.15
Bionic kernel.
Would it be possible to apply these patches set to Bionic? And it will
make sure v4.15 is correct.
The following patch isn't needed for Bionic v4.15 as it was merged in
v4.10-rc1.
9c2791f936ef sched/fair: Fix hierarchical order in rq->leaf_cfs_rq_list
$ git describe --contains 9c2791f936ef5fd04a118b5c284f2c9a95f4a647
v4.10-rc1~189^2~27
On Sat, Oct 12, 2019 at 12:02 AM Tyler Hicks <tyhicks at canonical.com> wrote:
> [+Gavin since he SRU'ed the fix for 1747896. Let's keep him cc'ed on any
> resubmissions.]
>
> On 2019-09-27 11:54:49, Connor Kuehl wrote:
> >
> https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-20784.html
> >
> > From the link above:
> >
> > "In the Linux kernel before 4.20.2, kernel/sched/fair.c mishandles
> leaf
> > cfs_rq's, which allows attackers to cause a denial of service
> (infinite
> > loop in update_blocked_averages) or possibly have unspecified
> other impact
> > by inducing a high load."
> >
> > Note, this fix reverts another patch that was specifically SRU'd in to
> > Xenial: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1747896
> >
> > In the hopes of avoiding a trade of 1 regression for another, I did a
> bit of an
> > A/B test to see if I could experience any blatant issues.
> >
> > I booted Xenial in a 64 bit VM twice. The first time was without this
> > CVE backport applied. The second time was with it applied. I ran the
> > reproducer in both cases and experienced the same CPU utilization (both
> > cores I allocated to my VM were at 100%) and in both cases I experienced
> > stable memory pressure. They would both hover around 120MB +/- 3-5MB.
> >
> > The primary difference between the two runs was where I'd watch the
> > cfs_rqs:
> >
> > WITHOUT the CVE backport: the cfs_rqs fluctuated between 13-18
> >
> > WITH the CVE backport: the cfs_rqs started around 65, then floated down
> > to 61.
>
> This seems to indicate that a portion of the [Impact] section from bug
> 1747896 is reintroduced. Specifically, "Also, the OOM happens because of
> the decayed cfs_rqs are not released."
>
> I didn't look too closely but I suspect that we need the equivalence of
> this patch sequence to fix CVE-2018-20784 and not reintroduce bug
> 1747896:
>
> 039ae8bcf7a5 sched/fair: Fix O(nr_cgroups) in the load balancing path
> 31bc6aeaab1d sched/fair: Optimize update_blocked_averages()
> f6783319737f sched/fair: Fix insertion in rq->leaf_cfs_rq_list
> c40f7d74c741 sched/fair: Fix infinite loop in update_blocked_averages()
> by reverting a9e7f6544b9c
>
> Tyler
>
> >
> > If there are more tests that anyone would like to see performed before
> > we settle on a decision for this backport, please let me know. I'm happy
> > to do it.
> >
> > - Connor
> >
> > Linus Torvalds (1):
> > sched/fair: Fix infinite loop in update_blocked_averages() by
> > reverting a9e7f6544b9c
> >
> > kernel/sched/fair.c | 44 ++++++++++----------------------------------
> > 1 file changed, 10 insertions(+), 34 deletions(-)
> >
> > --
> > 2.17.1
> >
> >
> > --
> > kernel-team mailing list
> > kernel-team at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/kernel-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20191026/25d6cb7d/attachment-0001.html>
More information about the kernel-team
mailing list