linux-kernel - Re: [RESEND PATCH v2] of: fix kmemleak crash caused by imbalance in early memory reservation

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] [day] [month] [year] [list]

Message-ID: <48ccaa25-725d-e72c-391a-5a078e1c7f77@roeck-us.net>
Date:   Wed, 6 Mar 2019 08:18:13 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Marc Gonzalez <marc.w.gonzalez@...e.fr>,
        Frank Rowand <frowand.list@...il.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Prateek Patel <prpatel@...dia.com>,
        DT <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RESEND PATCH v2] of: fix kmemleak crash caused by imbalance in
 early memory reservation

On 3/6/19 5:39 AM, Rob Herring wrote:
> On Tue, Mar 5, 2019 at 8:12 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On Tue, Feb 12, 2019 at 04:12:24PM -0600, Rob Herring wrote:
>>> On Tue, Feb 12, 2019 at 3:50 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> On Tue, 12 Feb 2019 10:03:09 -0600 Rob Herring <robh+dt@...nel.org> wrote:
>>>>>
>>>>> On Mon, Feb 11, 2019 at 10:47 AM Marc Gonzalez <marc.w.gonzalez@...e.fr> wrote:
>>>>>>
>>>>>> On 04/02/2019 15:37, Marc Gonzalez wrote:
>>>>>>
>>>>>>> Cc: stable@...r.kernel.org # 3.15+
>>>>>>> Fixes: 3f0c820664483 ("drivers: of: add initialization code for dynamic reserved memory")
>>>>>>> Acked-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>>>>>> Acked-by: Prateek Patel <prpatel@...dia.com>
>>>>>>> Tested-by: Marc Gonzalez <marc.w.gonzalez@...e.fr>
>>>>>>> Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
>>>>>>> ---
>>>>>>> Resend with DT CCed to reach robh's patch queue
>>>>>>> I added CC: stable, Fixes, and Prateek's ack
>>>>>>> Trim recipients list to minimize inconvenience
>>>>>>
>>>>>> I'm confused over commit 3532b3b554a216f30edb841d29eef48521bdc592 in linux-next
>>>>>> "memblock: drop __memblock_alloc_base()"
>>>>>>
>>>>>> It's definitely going to conflict with the proposed patch
>>>>>> over drivers/of/of_reserved_mem.c
>>>>>>
>>>>>> Rob, what's the next step then?
>>>>>
>>>>> Rebase it on top of what's in linux-next and apply it to the tree
>>>>> which has the above dependency. I'm guessing that is Andrew Morton's
>>>>> tree.
>>>>
>>>> Yeah, that is in Andrew's "post linux-next" patch series, so if you
>>>> rebase it on top of linux-next and then send it to Andrew with some
>>>> explanation.
>>>>
>>>> ...
>>>>
>>>> Actually, if it is intended for the stable trees, then presumably it is
>>>> intended to go to Linus for the current release?  In which case, the
>>>> patch in Andrew's tree will have to be changed to cope after your patch
>>>> appears in Linus' tree (and therefore, linux-next).
>>>
>>> At this point in the cycle, I wasn't planning to send this for 5.0.
>>> It's not fixing something introduced in 5.0 and it is a debug feature.
>>>
>> Hi Rob,
>>
>> this may be a debug feature, but we do test our kernels with it enabled,
>> and the problem does affect our 4.19 branch (chromeos-4.19). Are you
>> suggesting that we should backport the fix into our branch and not send
>> the backport to -stable ?
> 
> No, not at all. Just that I wasn't going to add it to the probable
> last 5.0-rc and would wait.
> 
> However, it's complicated by other memblock changes in 5.1 and not a
> trivial backport. One of the versions on the list should be easier to
> backport than what's in mainline (or going to be).
> 

We went ahead and applied a backport of an older version of the patch series
to chromeos-4.19. We'll see how well that works, but so far it looks like
it fixes our problem.

Guenter