linux-kernel - Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when expanding vma during mremap

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: <e8a679eb-e40c-481d-b65a-d16f9e66c19a@redhat.com>
Date: Sat, 24 May 2025 23:45:46 +0200
From: David Hildenbrand <david@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>, Pu Lehui <pulehui@...weicloud.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: mhiramat@...nel.org, peterz@...radead.org, akpm@...ux-foundation.org,
 Liam.Howlett@...cle.com, vbabka@...e.cz, jannh@...gle.com, pfalcato@...e.de,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, pulehui@...wei.com,
 Andrii Nakryiko <andrii@...nel.org>, Jiri Olsa <jolsa@...nel.org>
Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when
 expanding vma during mremap

On 24.05.25 18:45, Oleg Nesterov wrote:
> I am very glad that mm experts are already looking into this problem ;)
> I can't help, today I don't understand mm/vma.c even remotely. But let
> me ask a couple of stupid questions.
> 
>> However, the
>> upcomming move_page_tables step, which use set_pte_at to remap the vma2
>> uprobe anon page to the merged vma, will over map the old uprobe anon
>> page in the merged vma, and lead the old uprobe anon page to be orphan.
> 
> To be honest, I can't even understand this part due to my ignorance.
> What does "the old uprobe anon page to be orphan" actually mean?
> How can the unnecessary uprobe_mmap() lead to an "unbalanced"
> inc_mm_counter(MM_ANONPAGES) ? Or what else can explain the
> "BUG: Bad rss-counter state" from check_mm() ? Or there are more problems?

Essentially, we end up mapping an anonymous page (when install the 
uprobe) after preparing the new VMA, but before moving over the pages 
from the old VMA.

So when we then move over the pages from the old VMA, we overwrite the 
PTE mapping an anonymous page (due to uprobe).

As we simply overwrite the PTE that is mapping an anonymous page, we run 
into inconsistency later: RSS counter mismatch, memory leak, etc.

We should never be installing an anonymous page (due to uprobe) into a 
VMA during mremap() before moving over the pages from the old VMA.

-- 
Cheers,

David / dhildenb