From: sashiko-bot@kernel.org
To: "Yehyeong Lee" <yhlee@isslab.korea.ac.kr>
Cc: "Eugenio Perez" <eperezma@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
virtualization@lists.linux.dev
Subject: Re: [PATCH] iommu/virtio: bound the probe-property walk to the probe buffer
Date: Thu, 08 Oct 2026 09:56:03 +0000 [thread overview]
Message-ID: <sashiko-outbox-163970@kernel.org> (raw)
In-Reply-To: <20261008094240.1082031-1-yhlee@isslab.korea.ac.kr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] iommu/virtio: unaligned 64-bit access due to unvalidated property length
--
commit 1966676bc77a49f0f207bc2272bebf67d2bd8f06
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
iommu/virtio: bound the probe-property walk to the probe buffer
This commit prevents an out-of-bounds read in viommu_probe_endpoint() by
checking if the property fits within the probe allocation before
dereferencing it. It also moves the length check in viommu_add_resv_mem()
ahead of the memory accesses to avoid reading past the end of the
allocation.
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 587fc13197f12..dbc997a6e3568 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -489,6 +489,9 @@ static int viommu_add_resv_mem(struct viommu_endpoint *vdev,
> struct iommu_resv_region *region = NULL, *next;
> unsigned long prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
>
> + if (len < sizeof(*mem))
> + return -EINVAL;
> +
> start = start64 = le64_to_cpu(mem->start);
> end = end64 = le64_to_cpu(mem->end);
[Severity: High]
If a buggy or malicious device supplies an unaligned property length earlier
in the parsing loop, could the mem pointer passed to viommu_add_resv_mem()
be unaligned?
Because the virtio_iommu_probe_resv_mem structure is not packed, the
compiler assumes natural alignment. On architectures with strict alignment
requirements (such as ARM or SPARC), wouldn't these direct 64-bit
dereferences via le64_to_cpu() trigger a hardware alignment fault and lead
to a kernel panic?
[ ... ]
> @@ -563,8 +564,10 @@ static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
> type = le16_to_cpu(prop->type) & VIRTIO_IOMMU_PROBE_T_MASK;
>
> while (type != VIRTIO_IOMMU_PROBE_T_NONE &&
> - cur < viommu->probe_size) {
> + cur + sizeof(*prop) <= viommu->probe_size) {
> len = le16_to_cpu(prop->length) + sizeof(*prop);
> + if (len > viommu->probe_size - cur)
> + break;
[Severity: High]
The virtio-iommu specification requires property lengths to be 8-byte
aligned, but this length validation does not enforce alignment.
Can an unaligned property length from the untrusted device advance the cur
offset incorrectly?
viommu_probe_endpoint()
...
cur += len;
Wouldn't this cause subsequent property structures to be mapped to unaligned
memory addresses?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008094240.1082031-1-yhlee@isslab.korea.ac.kr?part=1
next prev parent reply other threads:[~2026-10-08 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 9:42 [PATCH] iommu/virtio: bound the probe-property walk to the probe buffer Yehyeong Lee
2026-10-08 9:56 ` sashiko-bot [this message]
2026-10-08 10:26 ` Yehyeong Lee
2026-10-08 10:59 ` Michael S. Tsirkin
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=sashiko-outbox-163970@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=virtualization@lists.linux.dev \
--cc=yhlee@isslab.korea.ac.kr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.