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 11:06:53 +0100
From:   Will Deacon <will.deacon@....com>
To:     Mark Brown <broonie@...nel.org>
Cc:     "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>,
        Mark Rutland <mark.rutland@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "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 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?

Will