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: <d2cb3a93-d5c6-4311-9a01-66fdc72608b7@lucifer.local>
Date: Thu, 3 Oct 2024 18:24:19 +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 Thu, Oct 03, 2024 at 07:07:37PM +0200, Bert Karwatzki wrote:
> Here's the log procduced by this kernel:
> 102b001a01be (HEAD -> maple_tree_debug_3) hack: set of info stuff v4
> 7e3bb072761a mm: correct error handling in mmap_region()
> 77df9e4bb222 (tag: next-20241001, origin/master, origin/HEAD, master) Add linux-next specific files for 20241001
>
> This patch actually changes the reproducability of the bug, it took three attempts to
> trigger it this time, so is there some kind of race here?

My working theory right now is you're happening to get a problematic maple
tree layout due to your unique setup and sequence of events (nobody else
can repro this not even with amd hardware), so the 'racey' element is
probably this more than aything else.

Everything happening to modify the maple tree is under lock so it seems
unlikely to me there's a race. The fact you can repro so reliably also
speaks to this.

Perhaps pausing to output this amount to the dmesg from the tree can tip it
into not triggering quite the right configuration but hard to tell.

I _suspect_ the maple tree has had some very subtle bug in a very specific
circumstance (overwriting a large number of entries that span multiple
nodes) that simply would not happen as we would overwrite most likely at
most 2 entries prior to the recent series (in your situation it appears to
be overwriting 6!).

Of course this is all theory at the moment and I may be wrong, but after
working flat out on this for the past couple days and obviously with your
kind assistance trying multiple possible causes from VMA code, I am fairly
sure it's something internal to the maple tree.

We know for sure it's the vma_iter_store() from the merge of a specific
range, thankfully wine is doing us a favour and explicitly mapping the same
exact ranges each time.

>
> Bert Karwatzki

[snip of huge log]

Thanks so much for this! Hopefully we should be able to figure out if there
is a maple tree bug here and repro it by constructing it :)

Again your help is much appreciated.

I will go off and see what I can do with this data, and _hopefully_ the
next request from me will be for you to try a fix again :)

Cheers, Lorenzo