linux-kernel - Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap

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: <81235f36-7266-4ce0-8175-7c4d0e6ae3de@lucifer.local>
Date: Tue, 1 Oct 2024 11:02:26 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Bert Karwatzki <spasswolf@....de>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap_region()

On Tue, Oct 01, 2024 at 11:57:02AM GMT, Bert Karwatzki wrote:
> Am Dienstag, dem 01.10.2024 um 10:49 +0100 schrieb Lorenzo Stoakes:
> > On Tue, Oct 01, 2024 at 10:20:02AM GMT, Lorenzo Stoakes wrote:
> > > On Tue, Oct 01, 2024 at 11:10:55AM GMT, Bert Karwatzki wrote:
> > > > It seems that the maple tree broke down, here's the result of the run with
> > > > CONFIG_DEBUG_MAPLETREE=y in all it's g(l)ory. (Here I didn't need to try to
> > > > kill
> > > > the processes to get an error and soon after the error occured everything
> > > > stopped working so I had to reboot via powerbutton.)
> > > >
> > > > Bert Karwatzki
> > >
> > > Yike thanks very much!
> > >
> > > If it's at all possible for you to confirm this happens on Linus's tree
> > > just to be super super sure (again I totally expect this) then that'd be
> > > amazing.
> > >
> > > I ask because we have another thread which bisected a problem to this
> > > commit which we didn't think was the cause and seemed actually to be the
> > > result of something else fiddling around with things it shouldn't so just
> > > want to entirely rule that out (a fix was applied to Linus's tree for
> > > that).
> > >
> > > [snip for snaity]
> >
> > OK so looking at the output it looks very much like your report is
> > unfortunate truncated...
> >
> > There is a 'BUG at mas_validate_limits:7523 (1)' report but immediately
> > prior to this there should be a line containing data formatted to "node%p:
> > data_end %u != the last slot offset %u".
>
> Actually one can just grab the report from /var/log/kern.log after a reboot, I
> just forgot to copy that line, here it is for the old report:

Well depends on distro etc. I suspect systemd systems probably store too but I
like to go with the 'easy' or at least straightforward option :P thanks though!
:)

>
> [ T4598] node00000000f48524f2: data_end 9 != the last slot offset 8
>
> and here's the error report from next-20241001:
>

Can you confirm that's definitely the first line in any bug report in dmesg from
boot? As after the first the tree is likely to get more corrupt and later
reports are just not going to be that useful.

Could you upload the full dmesg somewhere and give a link? Or send it
direct to me at lorenzo.stoakes@...cle.com? As pasting whole thing on list
might cause lore to sick up a bit. Possibly...

Thanks!

[snip]