linux-kernel - Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to

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:   Mon, 9 Oct 2017 13:42:26 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Will Deacon <will.deacon@....com>
Cc:     Mark Brown <broonie@...nel.org>,
        "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>,
        Mark Rutland <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Laura Abbott <labbott@...hat.com>
Subject: Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Mon, Oct 09, 2017 at 11:06:53AM +0100, Will Deacon wrote:
> On Mon, Oct 09, 2017 at 10:14:50AM +0100, Mark Brown wrote:
> > On Sat, Oct 07, 2017 at 03:10:06AM +0000, Levin, Alexander (Sasha Levin) wrote:
> > 
> > > We are experimenting with using neural network to aid with patch
> > > selection for stable kernel trees. There are quite a few commits that
> > > were not marked for stable, but are stable material, and we're trying
> > > to get them into their appropriate kernel trees.
> > 
> > If you're sending patches that were identified by a bot rather than a
> > domain expert it'd be really good to flag these *very* clearly (eg, by
> > sending the submissions with a different sender address) as they'll need
> > much more careful review than things that came in via a domain expert.
> > When they come from someone who's a stable maintainer as part of a big
> > batch of patches that doesn't look like a new submission from a not that
> > trusted source.
> 
> Taking this a bit further, I think ideally the subject would identify
> whether or not the patch was selected by a bot, and it shouldn't get
> backported to stable unless either the author or maintainer acks the patch,
> or there is a tested-by from somebody reporting that it fixes a bug on
> that stable tree that has actually been seen without it.
> 
> On the flip side, it means that the default response (silence) stops the
> patches getting into stable, which isn't ideal for Greg. Thoughts?

Yeah, default "do not take" isn't going to work, let's try just adding
another "this was picked because..." type line instead.

I know Sasha goes over these, and so do I, much more carefully than the
"normal" stable patches.  But things slip in, like this one, at times.

thanks,

greg k-h