linux-kernel - Re: Kmap-related crashes and memory leaks on 32bit arch (5.15+)

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: <20211116154338.GQ28560@twin.jikos.cz>
Date:   Tue, 16 Nov 2021 16:43:38 +0100
From:   David Sterba <dsterba@...e.cz>
To:     dsterba@...e.cz, Linus Torvalds <torvalds@...ux-foundation.org>,
        Qu Wenruo <wqu@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: Kmap-related crashes and memory leaks on 32bit arch (5.15+)

On Fri, Nov 05, 2021 at 08:50:04PM +0100, David Sterba wrote:
> On Thu, Nov 04, 2021 at 04:37:25PM -0700, Linus Torvalds wrote:
> > On Thu, Nov 4, 2021 at 3:09 PM Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > > If (a) works, but (b) still fails, then it must be some odd
> > > interaction issug withs-----ing else. Which sounds unlikely, since I
> > > don't think we really had anything that should affect kmap or anything
> > > in this area, but who knows...
> > 
> > And bisection ends up perhaps somewhat painful, but sounds like the
> > way to go if there's no other path forward.
> 
> Just to give an update, I tested several merge commits and the btrfs
> merge is the first bad (037c50bfbeb33b4c).
> 
> Last good is the one right before that,
> 
> 9c6e8d52a7299  Merge tag 'exfat-for-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
> (plus the fixup to make it compile e66435936756d9bce)
> 
> The remaining test to do is the merge conflict resolved by me, as you
> suggested.

So the result is that the merge conflict from Linus resolved the kmaps
correctly, there was a bug in the lzo refactoring patch itself that
caused some page array overflow and some random address was accessed.

I'll send a pull request in a day, I've been validating the patch on the
unmerged base and on rc1, also with various debugging options on.
Curiously, with SLOB there's an early crash while still doing the
compression, but with SLUB (and debugging enabled) there is not an
immediate crash but some other warning/assertion notices a page with
mapping (unexpected).