All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ryan Roberts" <ryan.roberts@arm.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	robh@kernel.org, conor+dt@kernel.org,
	"Oliver Upton" <oupton@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>
Subject: Re: [RFC PATCH v2 12/15] vfio: Support VFIO devices that access the CPU MMU
Date: Thu, 15 Oct 2026 14:44:11 +0000	[thread overview]
Message-ID: <sashiko-outbox-172976@kernel.org> (raw)
In-Reply-To: <20261015142552.4128028-13-ryan.roberts@arm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] vfio: NULL pointer dereference in vfio_df_iommufd_bind() via cdev ioctl
- [High] vfio: NULL pointer deref when binding IOMMUFD to CPU_MMU cdev
--

commit 147c0e7516a85b91b63d3c3d8f78088a9ca5c65f
Author: Jean-Philippe Brucker <jpb@kernel.org>

vfio: Support VFIO devices that access the CPU MMU

Support devices that are attached to a CPU and perform DMA through a
MMU without an IOMMU or VFIO container. The VMM uses device-specific
knowledge to handle virtual device creation.

> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 423ead48aafe3..41fee81a14cbb 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -344,7 +344,8 @@ static int __vfio_register_dev(struct vfio_device *device,
>  {
>  	int ret;
>  
> -	if (WARN_ON(IS_ENABLED(CONFIG_IOMMUFD) &&
> +	if (type != VFIO_CPU_MMU &&
> +	    WARN_ON(IS_ENABLED(CONFIG_IOMMUFD) &&
>  		    (!device->ops->bind_iommufd ||
>  		     !device->ops->unbind_iommufd ||
>  		     !device->ops->attach_ioas ||
>  		     !device->ops->detach_ioas)))
>  		return -EINVAL;

[Severity: High]
Could this bypass lead to a NULL pointer dereference for users of the
character device interface?

When CONFIG_VFIO_DEVICE_CDEV is enabled, vfio_device_add() automatically
creates a character device node (e.g., /dev/vfio/devices/vfioX) for the
registered device. If an untrusted user opens this cdev file and invokes
the VFIO_DEVICE_BIND_IOMMUFD ioctl, the request routes through the
following path:

vfio_df_ioctl_bind_iommufd()
  vfio_df_open()
    vfio_df_device_first_open()
      vfio_df_iommufd_bind()

Inside vfio_df_iommufd_bind() in drivers/vfio/iommufd.c, the code 
unconditionally executes:

return vdev->ops->bind_iommufd(vdev, ictx, &df->devid);

Since the updated check permits VFIO_CPU_MMU devices to be registered 
without providing a bind_iommufd callback, this would result in an
immediate NULL pointer dereference. 

Similarly, calling the VFIO_DEVICE_ATTACH_IOMMUFD_PT ioctl on the cdev 
unconditionally dereferences the attach_ioas pointer in 
vfio_df_ioctl_attach_pt(), which would also crash the kernel.

Should there be explicit checks in the cdev ioctl handlers to return
-EOPNOTSUPP for devices lacking these callbacks, or should VFIO_CPU_MMU 
devices perhaps be excluded from cdev creation entirely?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015142552.4128028-1-ryan.roberts@arm.com?part=12

  reply	other threads:[~2026-10-15 14:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 14:25 [RFC PATCH v2 00/15] Arm Core Local Accelerator Driver Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 01/15] misc/arm-cla: Add driver skeleton and documentation Ryan Roberts
2026-10-15 14:35   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 02/15] misc/arm-cla: Add launch operation helpers Ryan Roberts
2026-10-15 14:42   ` sashiko-bot
2026-10-15 16:17   ` Greg Kroah-Hartman
2026-10-15 16:32     ` Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 03/15] dt-bindings: misc: Add Arm Core Local Accelerator Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 04/15] misc/arm-cla: Probe firmware-described devices Ryan Roberts
2026-10-15 14:37   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 05/15] misc/arm-cla: Initialize devices on CPU bringup Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 06/15] misc/arm-cla: Accelerator context save and restore Ryan Roberts
2026-10-15 14:41   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 07/15] misc/arm-cla: Set up memory translation context Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 08/15] misc/arm-cla: Manage domain contexts Ryan Roberts
2026-10-15 14:38   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 09/15] misc/arm-cla: Add userspace interface Ryan Roberts
2026-10-15 14:47   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 10/15] KVM: arm64: Introduce support to pin VMIDs Ryan Roberts
2026-10-15 14:38   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 11/15] KVM: arm64: Export stage-2 MMU config Ryan Roberts
2026-10-15 14:43   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 12/15] vfio: Support VFIO devices that access the CPU MMU Ryan Roberts
2026-10-15 14:44   ` sashiko-bot [this message]
2026-10-15 16:44   ` Jason Gunthorpe
2026-10-15 14:25 ` [RFC PATCH v2 13/15] misc/arm-cla: Add stage-2 MTC and VM context switch Ryan Roberts
2026-10-15 14:40   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 14/15] misc/arm-cla: Support exclusive context assignment Ryan Roberts
2026-10-15 14:41   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 15/15] misc/arm-cla: Add vfio-mdev user interface Ryan Roberts
2026-10-15 14:49   ` sashiko-bot
2026-10-15 16:41   ` Jason Gunthorpe

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-172976@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=robh@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.