linux-kernel - Re: [syzbot ci] Re: Fix stale IOTLB entries for kernel address space

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: <4f2066f8-f26e-4704-9f75-4652d4018cd9@redhat.com>
Date: Mon, 20 Oct 2025 16:26:00 +0200
From: David Hildenbrand <david@...hat.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>, Dave Hansen <dave.hansen@...el.com>,
 syzbot ci <syzbot+cid009622971eb4566@...kaller.appspotmail.com>,
 akpm@...ux-foundation.org, apopple@...dia.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, iommu@...ts.linux.dev, jannh@...gle.com,
 jean-philippe@...aro.org, jgg@...dia.com, joro@...tes.org,
 kevin.tian@...el.com, liam.howlett@...cle.com, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, lorenzo.stoakes@...cle.com, luto@...nel.org,
 mhocko@...nel.org, mingo@...hat.com, peterz@...radead.org,
 robin.murphy@....com, rppt@...nel.org, security@...nel.org,
 stable@...r.kernel.org, tglx@...utronix.de, urezki@...il.com,
 vasant.hegde@....com, vbabka@...e.cz, will@...nel.org, willy@...radead.org,
 x86@...nel.org, yi1.lai@...el.com
Cc: syzbot@...ts.linux.dev, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot ci] Re: Fix stale IOTLB entries for kernel address space

On 20.10.25 07:34, Baolu Lu wrote:
> On 10/18/25 01:10, David Hildenbrand wrote:
>> On 16.10.25 10:00, Baolu Lu wrote:
>>> On 10/16/25 00:25, Dave Hansen wrote:
>>>> Here's the part that confuses me:
>>>>
>>>> On 10/14/25 13:59, syzbot ci wrote:
>>>>> page last free pid 5965 tgid 5964 stack trace:
>>>>>     reset_page_owner include/linux/page_owner.h:25 [inline]
>>>>>     free_pages_prepare mm/page_alloc.c:1394 [inline]
>>>>>     __free_frozen_pages+0xbc4/0xd30 mm/page_alloc.c:2906
>>>>>     pmd_free_pte_page+0xa1/0xc0 arch/x86/mm/pgtable.c:783
>>>>>     vmap_try_huge_pmd mm/vmalloc.c:158 [inline]
>>>> ...
>>>>
>>>> So, vmap_try_huge_pmd() did a pmd_free_pte_page(). Yet, somehow, the PMD
>>>> stuck around so that it *could* be used after being freed. It _looks_
>>>> like pmd_free_pte_page() freed the page, returned 0, and made
>>>> vmap_try_huge_pmd() return early, skipping the pmd pmd_set_huge().
>>>>
>>>> But I don't know how that could possibly happen.
>>>
>>> The reported issue is only related to this patch:
>>>
>>> - [PATCH v6 3/7] x86/mm: Use 'ptdesc' when freeing PMD pages
>>>
>>> It appears that the pmd_ptdesc() helper can't be used directly here in
>>> this patch. pmd_ptdesc() retrieves the page table page that the PMD
>>> entry resides in:
>>>
>>> static inline struct page *pmd_pgtable_page(pmd_t *pmd)
>>> {
>>>            unsigned long mask = ~(PTRS_PER_PMD * sizeof(pmd_t) - 1);
>>>            return virt_to_page((void *)((unsigned long) pmd & mask));
>>> }
>>>
>>> static inline struct ptdesc *pmd_ptdesc(pmd_t *pmd)
>>> {
>>>            return page_ptdesc(pmd_pgtable_page(pmd));
>>> }
>>>
>>> while, in this patch, we need the page descriptor that a pmd entry
>>> points to.
>>
>> Ah. But that's just pointing at a leaf page table, right?
> 
> Yes, that points to a leaf page table.

Right, so I guess there is no simplifying that.

Like we have in pte_lockptr():

	return ptlock_ptr(page_ptdesc(pmd_page(*pmd)));

So page_ptdesc(pmd_page()) is the way to go for now.

Sorry for the confusion.

-- 
Cheers

David / dhildenb