linux-kernel - Re: 6.10/bisected/regression - commit 8430557fc584 cause warning at mm/page_table_check.c:198 __page_table_check_ptes

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]

Date: Wed, 22 May 2024 09:48:51 +0200
From: David Hildenbrand <david@...hat.com>
To: Peter Xu <peterx@...hat.com>,
 Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
Cc: Pavel Tatashin <pasha.tatashin@...een.com>, axelrasmussen@...gle.com,
 nadav.amit@...il.com, Andrew Morton <akpm@...ux-foundation.org>,
 Linux Memory Management List <linux-mm@...ck.org>,
 Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: 6.10/bisected/regression - commit 8430557fc584 cause warning at
 mm/page_table_check.c:198 __page_table_check_ptes_set+0x306

On 22.05.24 00:36, Peter Xu wrote:
> On Wed, May 22, 2024 at 03:21:04AM +0500, Mikhail Gavrilov wrote:
>> On Wed, May 22, 2024 at 2:37 AM Peter Xu <peterx@...hat.com> wrote:
>>> Hmm I still cannot reproduce.  Weird.
>>>
>>> Would it be possible for you to identify which line in debug_vm_pgtable.c
>>> triggered that issue?
>>>
>>> I think it should be some set_pte_at() but I'm not sure, as there aren't a
>>> lot and all of them look benign so far.  It could be that I missed
>>> something important.
>>
>> I hope it's helps:
> 
> Thanks for offering this, it's just that it doesn't look coherent with what
> was reported for some reason.
> 
>>
>>> sh /usr/src/kernels/(uname -r)/scripts/faddr2line /lib/debug/lib/modules/(uname -r)/vmlinux debug_vm_pgtable+0x1c04
>> debug_vm_pgtable+0x1c04/0x3360:
>> native_ptep_get_and_clear at arch/x86/include/asm/pgtable_64.h:94
>> (inlined by) ptep_get_and_clear at arch/x86/include/asm/pgtable.h:1262
>> (inlined by) ptep_clear at include/linux/pgtable.h:509
> 
> This is a pte_clear(), and pte_clear() shouldn't even do the set() checks,
> and shouldn't stumble over what I added.
> 
> IOW, it doesn't match with the real stack dump previously:
> 
> [    5.581003]  ? __page_table_check_ptes_set+0x306/0x3c0
> [    5.581274]  ? __pfx___page_table_check_ptes_set+0x10/0x10
> [    5.581544]  ? __pfx_check_pgprot+0x10/0x10
> [    5.581806]  set_ptes.constprop.0+0x66/0xd0
> [    5.582072]  ? __pfx_set_ptes.constprop.0+0x10/0x10
> [    5.582333]  ? __pfx_pte_val+0x10/0x10
> [    5.582595]  debug_vm_pgtable+0x1c04/0x3360
> 

Staring at pte_clear_tests():

#ifndef CONFIG_RISCV
	pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
#endif
	set_pte_at(args->mm, args->vaddr, args->ptep, pte);

So we set random PTE bits, probably setting the present, uffd and write 
bit at the same time. That doesn't make too much sense when we want to 
perform that such combinations cannot exist.

In pmd_clear_tests() and friends we use WRITE_ONCE() instead, so there 
we don't run into trouble.

-- 
Cheers,

David / dhildenb