linux-kernel - Re: [PATCH] MIPS: pgalloc: fix memory leak caused by pgd

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: <alpine.DEB.2.21.2204051027490.47162@angie.orcam.me.uk>
Date:   Tue, 5 Apr 2022 10:42:21 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Andrew Powers-Holmes <aholmes@...om.net>
cc:     yaliang.wang@...driver.com, rppt@...nel.org,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        huangpei@...ngson.cn, Andrew Morton <akpm@...ux-foundation.org>,
        kumba@...too.org, Geert Uytterhoeven <geert@...ux-m68k.org>,
        anshuman.khandual@....com, penberg@...nel.org,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] MIPS: pgalloc: fix memory leak caused by pgd_free()

On Mon, 4 Apr 2022, Andrew Powers-Holmes wrote:

> Fair enough :) apologies, didn't mean to sound combative or ungrateful.
> I know there's far more work to go around than people to do it,
> everyone's doing the best they can, and I have nothing but appreciation
> for all the work the kernel community does.

 No offence taken; I just wanted to make it absolutely clear what the 
situation currently is.

> It's just surprising that this *could* go unnoticed for over a year -
> though I suppose most of the MIPS64 systems out there are running on one
> or another old vendor SDK kernel so won't have been affected...

 That's subject to the probability theory and depending on what people's 
usage models are.

> Would the best way to get this merged into 5.10/15 (and maybe .16 just
> for good measure) be to email the stable team (since it's already in
> Linus' tree)? Documentation/process/stable-kernel-rules seems to say
> yes, but I'd like to avoid stepping on anyone's toes given that it's not
> my patch.

 You seem the most severely affected so far, so why not act in your best 
interest?  I think option #2 applies here and seems quite straightforward 
to follow, referring commit 2bc5bab9a763 and using your use case as the 
justification.  It doesn't have to be the author to request a backport.

 NB I think it has to be backported to all the stable branches made since 
the original breakage; i.e. v5.9+ (I haven't kept track of what they are).

  Maciej