From: Jason Gunthorpe <jgg@ziepe.ca>
To: Fedor Pchelkin <pchelkin@ispras.ru>
Cc: Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>, Kevin Tian <kevin.tian@intel.com>,
Nicolin Chen <nicolinc@nvidia.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org
Subject: Re: [PATCH] iommu: fix crash in report_iommu_fault()
Date: Tue, 8 Apr 2025 18:38:28 -0300 [thread overview]
Message-ID: <20250408213828.GC1727154@ziepe.ca> (raw)
In-Reply-To: <20250408213342.285955-1-pchelkin@ispras.ru>
On Wed, Apr 09, 2025 at 12:33:41AM +0300, Fedor Pchelkin wrote:
> The following crash is observed while handling an IOMMU fault with a
> recent kernel:
>
> kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> BUG: unable to handle page fault for address: ffff8c708299f700
> PGD 19ee01067 P4D 19ee01067 PUD 101c10063 PMD 80000001028001e3
> Oops: Oops: 0011 [#1] SMP NOPTI
> CPU: 4 UID: 0 PID: 139 Comm: irq/25-AMD-Vi Not tainted 6.15.0-rc1+ #20 PREEMPT(lazy)
> Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024
> RIP: 0010:0xffff8c708299f700
> Call Trace:
> <TASK>
> ? report_iommu_fault+0x78/0xd3
> ? amd_iommu_report_page_fault+0x91/0x150
> ? amd_iommu_int_thread+0x77/0x180
> ? __pfx_irq_thread_fn+0x10/0x10
> ? irq_thread_fn+0x23/0x60
> ? irq_thread+0xf9/0x1e0
> ? __pfx_irq_thread_dtor+0x10/0x10
> ? __pfx_irq_thread+0x10/0x10
> ? kthread+0xfc/0x240
> ? __pfx_kthread+0x10/0x10
> ? ret_from_fork+0x34/0x50
> ? __pfx_kthread+0x10/0x10
> ? ret_from_fork_asm+0x1a/0x30
> </TASK>
>
> report_iommu_fault() checks for an installed handler comparing the
> corresponding field to NULL. It can (and could before) be called for a
> domain with a different cookie type - IOMMU_COOKIE_DMA_IOVA, specifically.
> Cookie is represented as a union so we may end up with a garbage value
> treated there if this happens for a domain with another cookie type.
>
> Formerly there were two exclusive cookie types in the union.
> IOMMU_DOMAIN_SVA has a dedicated iommu_report_device_fault().
>
> Call the fault handler only if the passed domain has a required cookie
> type.
>
> Found by Linux Verification Center (linuxtesting.org).
>
> Fixes: 6aa63a4ec947 ("iommu: Sort out domain user data")
> Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
> ---
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
This should go to rc
> > iommu-dma itself isn't ever going to use a fault
> > handler because it expects the DMA API to be used correctly and thus no
> > faults to occur.
>
> My first thought about this is that iommu-dma is not interested in
> installing a fault handler ever, okay. But why does it suppose that no
> faults would occur? It is a matter of "chance", firmware bugs, abovesaid
> DMA API abusing, etc... isn't it?
Yes, it should not happen, this driver is clearly buggy.
Jason
next prev parent reply other threads:[~2025-04-08 21:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 21:33 [PATCH] iommu: fix crash in report_iommu_fault() Fedor Pchelkin
2025-04-08 21:38 ` Jason Gunthorpe [this message]
2025-04-09 11:30 ` Robin Murphy
2025-04-10 5:29 ` Tian, Kevin
2025-04-10 13:00 ` Jason Gunthorpe
2025-04-10 5:21 ` Tian, Kevin
2025-04-11 7:05 ` Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250408213828.GC1727154@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=nicolinc@nvidia.com \
--cc=pchelkin@ispras.ru \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox