linux-kernel - Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Dec 2017 11:30:38 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Michal Hocko <mhocko@...nel.org>
Cc:     alexander.levin@...izon.com,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Shakeel Butt <shakeelb@...gle.com>
Subject: Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to
 kmemcg

On 23/12/2017 10:24, Greg Kroah-Hartman wrote:
> For many subsystems, the maintainers _never_ mark patches for stable.
> Others, they catch maybe half of the things they should be applying.
> 
> KVM is one such example of the "half" group, they mark patches as
> resolving CVE issues at times, yet don't mark them for stable.  So when
> I see a patch like this, it triggers the "oh, look, KVM doing the same
> thing again", so I take the patch and of course cc: the
> developers/maintainers so they can object if they want to.

In general there are some cases where I tend to be conservative on
applying the "stable" tag, for example:

1) sometimes I'm not very familiar with API changes in the other
subsystems (this was the case for this patch).  If I am not sure of the
amount of backporting effort required, and the bug is not super
important, I don't mark it as stable because I don't want to later drop
a complex backport on the floor.  I prefer to have fewer patches
applied, but know that the fixes are backported to all branches.

2) not all bugs are equal; a WARN_ON_ONCE from a syzkaller testcase for
example doesn't really matter to a cloud provider that uses KVM, because
invalid API usage is not controlled by the customer.  But an oops or
BUG_ON probably *will* get CCed to stable.  So some patches for
syzkaller bugs may be CCed, some may not.

IIRC the CVE that you mention was a guest user->kernel escalation, but
it didn't affect Linux guests at all, and it couldn't be fixed
completely on Windows guests because Windows has another bug in the same
area.  Plus, I knew there would be different conflicts on all LTS
branches, so I decided to not mark it for stable.  I did dutifully
provide a backport when someone (either you or Ben Hutchings) asked for
one, though.

It does happen that Radim or I forget to Cc stable, so I'm okay with you
picking up more patches than what I mark and I will happily do the
backports for you.  Still, there is some thought put into whether to CC
stable or not. :)

Thanks,

Paolo

> Over time you get to know what subsystems are like this and what are
> not.  MM is one that is really good, I almost never take a mm patch
> without being told explicitly to do so.  Others are horrible and never
> mark anything, so stuff has to be picked up manually through Sasha's
> process or through other ways.
> 
> So it's not a perfect system, but it seems to work "good enough", and if
> you ever have any questions about any patch, always feel free to ask,
> there's usually a story behind almost every one...