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: <6884ca9a-f63d-d6ef-9ead-68ab672098ec@redhat.com> 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...
Powered by blists - more mailing lists