Kernel KVM virtualization development
 help / color / mirror / Atom feed
* [PATCH 5.10 5.15] vfio/iommu_type1: replace kfree with kvfree
@ 2026-06-19 15:02 Nikolay Kuratov
  2026-06-19 15:13 ` sashiko-bot
  2026-06-21 13:47 ` Sasha Levin
  0 siblings, 2 replies; 3+ messages in thread
From: Nikolay Kuratov @ 2026-06-19 15:02 UTC (permalink / raw)
  To: stable
  Cc: linux-kernel, kvm, Kirti Wankhede, Yan Zhao, Nikolay Kuratov,
	Jiacheng Shi, Alex Williamson

From: Jiacheng Shi <billsjc@sjtu.edu.cn>

From: Jiacheng Shi <billsjc@sjtu.edu.cn>

commit 2bed2ced40c97b8540ff38df0149e8ecb2bf4c65 upstream.

Variables allocated by kvzalloc should not be freed by kfree.
Because they may be allocated by vmalloc.
So we replace kfree with kvfree here.

Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages tracking")
Signed-off-by: Jiacheng Shi <billsjc@sjtu.edu.cn>
Link: https://lore.kernel.org/r/20211212091600.2560-1-billsjc@sjtu.edu.cn
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru>
---
 drivers/vfio/vfio_iommu_type1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index f17490ab238f..9394aa9444c1 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -256,7 +256,7 @@ static int vfio_dma_bitmap_alloc(struct vfio_dma *dma, size_t pgsize)
 
 static void vfio_dma_bitmap_free(struct vfio_dma *dma)
 {
-	kfree(dma->bitmap);
+	kvfree(dma->bitmap);
 	dma->bitmap = NULL;
 }
 
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH 5.10 5.15] vfio/iommu_type1: replace kfree with kvfree
  2026-06-19 15:02 [PATCH 5.10 5.15] vfio/iommu_type1: replace kfree with kvfree Nikolay Kuratov
@ 2026-06-19 15:13 ` sashiko-bot
  2026-06-21 13:47 ` Sasha Levin
  1 sibling, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-06-19 15:13 UTC (permalink / raw)
  To: Nikolay Kuratov; +Cc: kvm

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Memory leak in vfio_dma_bitmap_alloc_all error path leading to DoS/OOM
- [High] Out-of-bounds user memory access on 32-bit platforms due to incorrect pointer arithmetic in update_user_bitmap
--

commit 40ca6fabb082675b1379a40ebe33b025f5ba2193
Author: Jiacheng Shi <billsjc@sjtu.edu.cn>

vfio/iommu_type1: replace kfree with kvfree

Variables allocated by kvzalloc should not be freed by kfree, because they
may be allocated by vmalloc. This replaces kfree with kvfree for dma->bitmap.

Link: https://lore.kernel.org/r/20211212091600.2560-1-billsjc@sjtu.edu.cn

> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 67e8276389951..65df5bbc71a8b 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -220,7 +220,7 @@ static int vfio_dma_bitmap_alloc(struct vfio_dma *dma, size_t pgsize)
>  
>  static void vfio_dma_bitmap_free(struct vfio_dma *dma)
>  {
> -	kfree(dma->bitmap);
> +	kvfree(dma->bitmap);
>  	dma->bitmap = NULL;
>  }

[Severity: High]
This isn't a bug introduced by this patch, but looking at the error path in
vfio_dma_bitmap_alloc_all() which calls this function:

drivers/vfio/vfio_iommu_type1.c:vfio_dma_bitmap_alloc_all() {
        ...
        for (p = rb_prev(n); p; p = rb_prev(p)) {
                struct vfio_dma *dma = rb_entry(n,
                                struct vfio_dma, node);
                vfio_dma_bitmap_free(dma);
        }
        ...
}

Does this code leak the previously allocated dma->bitmap memory?

The loop iterates backward using p, but it extracts the vfio_dma struct
using the failed node n instead of the loop iterator p. This causes the
error path to repeatedly free the failed node while leaking the successful
allocations.

Unprivileged users might be able to trigger this failure repeatedly via the
ioctl, which could exhaust memory.

[Severity: High]
This is a pre-existing issue, but can this pointer arithmetic cause
out-of-bounds user memory accesses on 32-bit platforms?

drivers/vfio/vfio_iommu_type1.c:update_user_bitmap() {
        ...
        unsigned long copy_offset = bit_offset / BITS_PER_LONG;
        ...
        if (copy_to_user((void __user *)(bitmap + copy_offset), dma->bitmap,
                         DIRTY_BITMAP_BYTES(nbits + shift)))
        ...
}

If the bitmap parameter is typed as a u64 pointer, advancing it by
copy_offset on 32-bit architectures (where BITS_PER_LONG is 32) will move
the pointer by copy_offset * 8 bytes.

Since copy_offset is bit_offset / 32, this advances the pointer by
bit_offset / 4 bytes instead of the expected bit_offset / 8 bytes.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619150206.1719815-1-kniv@yandex-team.ru?part=1

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 5.10 5.15] vfio/iommu_type1: replace kfree with kvfree
  2026-06-19 15:02 [PATCH 5.10 5.15] vfio/iommu_type1: replace kfree with kvfree Nikolay Kuratov
  2026-06-19 15:13 ` sashiko-bot
@ 2026-06-21 13:47 ` Sasha Levin
  1 sibling, 0 replies; 3+ messages in thread
From: Sasha Levin @ 2026-06-21 13:47 UTC (permalink / raw)
  To: stable
  Cc: Sasha Levin, linux-kernel, kvm, Kirti Wankhede, Yan Zhao,
	Nikolay Kuratov, Jiacheng Shi, Alex Williamson

> commit 2bed2ced40c97b8540ff38df0149e8ecb2bf4c65 upstream.
>
> Variables allocated by kvzalloc should not be freed by kfree.
> Because they may be allocated by vmalloc.
> So we replace kfree with kvfree here.

Queued for 5.10 and 5.15, thanks.

-- 
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-06-21 13:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-19 15:02 [PATCH 5.10 5.15] vfio/iommu_type1: replace kfree with kvfree Nikolay Kuratov
2026-06-19 15:13 ` sashiko-bot
2026-06-21 13:47 ` Sasha Levin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox