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: <89146527-3f41-4f1e-8511-0d06e169c09e@intel.com>
Date: Wed, 15 Oct 2025 09:25:55 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: syzbot ci <syzbot+cid009622971eb4566@...kaller.appspotmail.com>,
 akpm@...ux-foundation.org, apopple@...dia.com, baolu.lu@...ux.intel.com,
 bp@...en8.de, dave.hansen@...ux.intel.com, david@...hat.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

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.