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]

Message-ID: <20171009141021.jfbobr3r72cwg7pa@sirena.co.uk>
Date:   Mon, 9 Oct 2017 15:10:21 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Will Deacon <will.deacon@....com>,
        "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 01:42:26PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 09, 2017 at 11:06:53AM +0100, Will Deacon wrote:

> > 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.

It would be worth trying harder for review, at least for an initial
period while this is new and people perhaps aren't aware that it's
happening at all.  The suggestions for flagging things as not just being
normal stable stuff outside of the body of the message would help here,
something in the body of the message is going to get missed.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)