linux-kernel - RE: [PATCH v2 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush

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: <BN9PR11MB5276F8759367004AD36F6DA88C48A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Thu, 10 Jul 2025 08:15:27 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Yu Zhang <zhangyu1@...ux.microsoft.com>
CC: Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>, "Will
 Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....com>, "Jason
 Gunthorpe" <jgg@...dia.com>, Jann Horn <jannh@...gle.com>, Vasant Hegde
	<vasant.hegde@....com>, "Hansen, Dave" <dave.hansen@...el.com>, "Alistair
 Popple" <apopple@...dia.com>, Peter Zijlstra <peterz@...radead.org>,
	Uladzislau Rezki <urezki@...il.com>, Jean-Philippe Brucker
	<jean-philippe@...aro.org>, Andy Lutomirski <luto@...nel.org>, "Lai, Yi1"
	<yi1.lai@...el.com>, "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"security@...nel.org" <security@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: RE: [PATCH v2 1/1] iommu/sva: Invalidate KVA range on kernel TLB
 flush

> From: Yu Zhang <zhangyu1@...ux.microsoft.com>
> Sent: Thursday, July 10, 2025 4:11 PM
> 
> On Thu, Jul 10, 2025 at 03:02:07AM +0000, Tian, Kevin wrote:
> > > From: Lu Baolu <baolu.lu@...ux.intel.com>
> > > Sent: Wednesday, July 9, 2025 2:28 PM
> > >
> > > The vmalloc() and vfree() functions manage virtually contiguous, but not
> > > necessarily physically contiguous, kernel memory regions. When vfree()
> > > unmaps such a region, it tears down the associated kernel page table
> > > entries and frees the physical pages.
> > >
> > > In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU
> > > hardware
> > > shares and walks the CPU's page tables. Architectures like x86 share
> > > static kernel address mappings across all user page tables, allowing the
> >
> > I'd remove 'static'
> >
> > > IOMMU to access the kernel portion of these tables.
> > >
> > > Modern IOMMUs often cache page table entries to optimize walk
> > > performance,
> > > even for intermediate page table levels. If kernel page table mappings are
> > > changed (e.g., by vfree()), but the IOMMU's internal caches retain stale
> > > entries, Use-After-Free (UAF) vulnerability condition arises. If these
> > > freed page table pages are reallocated for a different purpose, potentially
> > > by an attacker, the IOMMU could misinterpret the new data as valid page
> > > table entries. This allows the IOMMU to walk into attacker-controlled
> > > memory, leading to arbitrary physical memory DMA access or privilege
> > > escalation.
> >
> > this lacks of a background that currently the iommu driver is notified
> > only for changes of user VA mappings, so the IOMMU's internal caches
> > may retain stale entries for kernel VA.
> >
> > >
> > > To mitigate this, introduce a new iommu interface to flush IOMMU caches
> > > and fence pending page table walks when kernel page mappings are
> updated.
> > > This interface should be invoked from architecture-specific code that
> > > manages combined user and kernel page tables.
> >
> > this also needs some words about the fact that new flushes are triggered
> > not just for freeing page tables.
> >
> Thank you, Kevin. A question about the background of this issue:
> 
> My understanding of the attacking scenario is, a malicious user application
> could initiate DMAs to some vmalloced address, causing the paging structure
> cache being loaded and then possibly being used after that paging structure
> is freed(may be allocated to some other users later).
> 
> If that is the case, only when the paging structures are freed, do we need
> to do the flush. I mean, the IOTLB entries may not be loaded at all when the
> permission check failes. Did I miss anything? :)
> 

It's about the paging structure cache instead of IOTLB.

You may look at the discussion in v1 for more background, especially
the latest reply from Baolu about a detailed example:

https://lore.kernel.org/linux-iommu/2080aaea-0d6e-418e-8391-ddac9b39c109@linux.intel.com/