linux-kernel - Re: [PATCH AUTOSEL 6.1 13/22] proc/vmcore: fix potential memory leak in vmcore

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y575UCk+lwfJ2CoE@sashalap>
Date:   Sun, 18 Dec 2022 06:28:16 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Jianglei Nie <niejianglei2021@....com>,
        Baoquan He <bhe@...hat.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Chen Lifu <chenlifu@...wei.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Li Chen <lchen@...arella.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Paul Mackerras <paulus@...ba.org>,
        Petr Mladek <pmladek@...e.com>,
        Russell King <linux@...linux.org.uk>,
        ye xingchen <ye.xingchen@....com.cn>,
        Zeal Robot <zealci@....com.cn>, kexec@...ts.infradead.org,
        linux-fsdevel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH AUTOSEL 6.1 13/22] proc/vmcore: fix potential memory leak
 in vmcore_init()

On Sat, Dec 17, 2022 at 04:32:28PM -0800, Andrew Morton wrote:
>On Sat, 17 Dec 2022 10:27:14 -0500 Sasha Levin <sashal@...nel.org> wrote:
>
>> From: Jianglei Nie <niejianglei2021@....com>
>>
>> [ Upstream commit 12b9d301ff73122aebd78548fa4c04ca69ed78fe ]
>>
>> Patch series "Some minor cleanup patches resent".
>>
>> The first three patches trivial clean up patches.
>>
>> And for the patch "kexec: replace crash_mem_range with range", I got a
>> ibm-p9wr ppc64le system to test, it works well.
>>
>> This patch (of 4):
>>
>> elfcorehdr_alloc() allocates a memory chunk for elfcorehdr_addr with
>> kzalloc().  If is_vmcore_usable() returns false, elfcorehdr_addr is a
>> predefined value.  If parse_crash_elf_headers() gets some error and
>> returns a negetive value, the elfcorehdr_addr should be released with
>> elfcorehdr_free().
>
>This is exceedingly minor - a single memory leak per boot, under very
>rare circumstances.
>
>
>With every patch I merge I consider -stable.  Often I'll discuss the
>desirability of a backport with the author and with reviewers.  Every
>single patch.  And then some damn script comes along and overrides that
>quite careful decision.  argh.
>
>Can we please do something like
>
>	if (akpm && !cc:stable)
>		dont_backport()

Yup, I already had it set for 'akpm && mm/ && !cc:stable', happy to
remove the 'mm/' restriction if you're doing the same for the rest of
the patches you review.

>And even go further - if your script thinks it might be something we
>should backport and if it didn't have cc:stable then contact the
>author, reviewers and committers and ask them to reconsider before we
>go and backport it.  This approach will have the advantage of training
>people to consider the backport more consistently.

This is what this mail is all about: I haven't queued up the patch yet,
it gives folks week+ to review, and all it takes is a simple "no" for me
to drop it.

>I'd (still) like to have a new patch tag like Not-For-Stable: or
>cc:not-stable or something to tell your scripts "yes, we thought about
>it and we decided no".

No objections on my part.

-- 
Thanks,
Sasha