Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Alex Williamson <alex@shazbot.org>
To: lirongqing <lirongqing@baidu.com>
Cc: <kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, alex@shazbot.org
Subject: Re: [PATCH] vfio: Validate that bitmap.pgsize is a power-of-2 in vfio_iommu_type1_unmap_dma
Date: Tue, 16 Jun 2026 17:14:07 -0600	[thread overview]
Message-ID: <20260616171407.54190e05@shazbot.org> (raw)
In-Reply-To: <20260616111733.1810-1-lirongqing@baidu.com>

On Tue, 16 Jun 2026 19:17:33 +0800
lirongqing <lirongqing@baidu.com> wrote:

> From: Li RongQing <lirongqing@baidu.com>
> 
> In vfio_iommu_type1_unmap_dma(), the user-supplied bitmap.pgsize is
> passed directly to __ffs() without sufficient validation.
> 
> If userspace passes bitmap.pgsize == 0, it triggers undefined behavior
> in __ffs(), resulting in an undefined return value. Furthermore,
> passing a non-power-of-2 value (e.g., 3 or 5) results in an incorrect
> pgshift value. In either case, the invalid pgshift miscalculates the
> shifted unmap size (unmap.size >> pgshift), which distorts the
> subsequent verify_bitmap_size() validation logic and allows
> inconsistent user inputs to bypass proper sanitization.
> 
> Fix this by introducing an explicit is_power_of_2() check on
> bitmap.pgsize before processing. This strictly ensures the page size
> conforms to valid IOMMU page size semantics while preventing any
> downstream arithmetic anomalies caused by zero or non-power-of-2
> inputs.

For there to be an actual bug here, __ffs(0) would need to generate a
fault, not just return a garbage value.  If the value gets past
verify_bitmap_size() we call vfio_dma_do_unmap(), where we test
(bitmap->pgsize != pgsize), and pgsize is:

        pgshift = __ffs(iommu->pgsize_bitmap);
        pgsize = (size_t)1 << pgshift;

So, while I agree that we shouldn't be generating and passing around
garbage, the assertion that it allows user input to get past
sanitization isn't true.

The sashiko find is the same pattern, same downstream catch; __ffs()
returns a garbage value that's revalidated before use, never a fault,
so those sites are equally benign.

If you'd still like to pursue it, scope the commit log with the correct
severity, address the matching GET_BITMAP pgsize path, and repost.
Thanks,

Alex


> Fixes: 331e33d2960c8 ("vfio iommu: Update UNMAP_DMA ioctl to get
> dirty bitmap before unmap") Signed-off-by: Li RongQing
> <lirongqing@baidu.com> ---
>  drivers/vfio/vfio_iommu_type1.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c index c8151ba..b05fde8 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -38,6 +38,7 @@
>  #include <linux/workqueue.h>
>  #include <linux/mm_inline.h>
>  #include <linux/overflow.h>
> +#include <linux/log2.h>
>  #include "vfio.h"
>  
>  #define DRIVER_VERSION  "0.2"
> @@ -2949,6 +2950,9 @@ static int vfio_iommu_type1_unmap_dma(struct
> vfio_iommu *iommu, if (!access_ok((void __user *)bitmap.data,
> bitmap.size)) return -EINVAL;
>  
> +		if (unlikely(!is_power_of_2(bitmap.pgsize)))
> +			return -EINVAL;
> +
>  		pgshift = __ffs(bitmap.pgsize);
>  		ret = verify_bitmap_size(unmap.size >> pgshift,
>  					 bitmap.size);


      parent reply	other threads:[~2026-06-16 23:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16 11:17 [PATCH] vfio: Validate that bitmap.pgsize is a power-of-2 in vfio_iommu_type1_unmap_dma lirongqing
2026-06-16 11:28 ` sashiko-bot
2026-06-16 23:14 ` Alex Williamson [this message]

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=20260616171407.54190e05@shazbot.org \
    --to=alex@shazbot.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    /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