[PATCH] iommufd: Initialize batch->kind field in pfn_batch

[PATCH] iommufd: Initialize batch->kind field in pfn_batch

[Fushuai Wang]

From: Fushuai Wang <wangfushuai@baidu.com>

The commit 3114c674401e ("iommufd: Allow MMIO pages in a batch")
added a new 'kind' field to struct pfn_batch but failed to initialize
it.

This leads to KMSAN detecting uninitialized-value usage when
batch->kind is first read in batch_add_pfn_num():
	iopt_pages_unfill_xarray+0x86/0x1660
	iopt_area_remove_access+0x508/0x650

Initialize batch->kind to BATCH_CPU_MEMORY in batch_clear{_array}.

Fixes: 3114c674401e ("iommufd: Allow MMIO pages in a batch")
Reported-by: syzbot+a0c841e02f328005bbcc@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6975b1f4.a00a0220.33ccc7.001f.GAE@google.com/T/
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
---
 drivers/iommu/iommufd/pages.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
index dbe51ecb9a20..064f2cf32cc1 100644
--- a/drivers/iommu/iommufd/pages.c
+++ b/drivers/iommu/iommufd/pages.c
@@ -289,6 +289,7 @@ static void batch_clear(struct pfn_batch *batch)
 	batch->end = 0;
 	batch->pfns[0] = 0;
 	batch->npfns[0] = 0;
+	batch->kind = BATCH_CPU_MEMORY;
 }
 
 /*
@@ -309,6 +310,7 @@ static void batch_clear_carry(struct pfn_batch *batch, unsigned int keep_pfns)
 			 (batch->npfns[batch->end - 1] - keep_pfns);
 	batch->npfns[0] = keep_pfns;
 	batch->end = 1;
+	batch->kind = BATCH_CPU_MEMORY;
 }
 
 static void batch_skip_carry(struct pfn_batch *batch, unsigned int skip_pfns)
-- 
2.36.1

RE: [PATCH] iommufd: Initialize batch->kind field in pfn_batch

[Tian, Kevin]

> From: Fushuai Wang <fushuai.wang@linux.dev>
> Sent: Monday, January 26, 2026 11:25 AM
> 
> From: Fushuai Wang <wangfushuai@baidu.com>
> 
> The commit 3114c674401e ("iommufd: Allow MMIO pages in a batch")
> added a new 'kind' field to struct pfn_batch but failed to initialize
> it.
> 
> This leads to KMSAN detecting uninitialized-value usage when
> batch->kind is first read in batch_add_pfn_num():
> 	iopt_pages_unfill_xarray+0x86/0x1660
> 	iopt_area_remove_access+0x508/0x650
> 
> Initialize batch->kind to BATCH_CPU_MEMORY in batch_clear{_array}.
> 
> Fixes: 3114c674401e ("iommufd: Allow MMIO pages in a batch")
> Reported-by: syzbot+a0c841e02f328005bbcc@syzkaller.appspotmail.com
> Closes:
> https://lore.kernel.org/all/6975b1f4.a00a0220.33ccc7.001f.GAE@google.co
> m/T/
> Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
> ---
>  drivers/iommu/iommufd/pages.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iommu/iommufd/pages.c
> b/drivers/iommu/iommufd/pages.c
> index dbe51ecb9a20..064f2cf32cc1 100644
> --- a/drivers/iommu/iommufd/pages.c
> +++ b/drivers/iommu/iommufd/pages.c
> @@ -289,6 +289,7 @@ static void batch_clear(struct pfn_batch *batch)
>  	batch->end = 0;
>  	batch->pfns[0] = 0;
>  	batch->npfns[0] = 0;
> +	batch->kind = BATCH_CPU_MEMORY;
>  }
> 
>  /*
> @@ -309,6 +310,7 @@ static void batch_clear_carry(struct pfn_batch
> *batch, unsigned int keep_pfns)
>  			 (batch->npfns[batch->end - 1] - keep_pfns);
>  	batch->npfns[0] = keep_pfns;
>  	batch->end = 1;
> +	batch->kind = BATCH_CPU_MEMORY;
>  }
> 

this is incorrect. 'carry' means a portion of previous batch was handed
over to the new batch, and it already initializes the array with a valid
item#0. So the old 'kind' type should be kept.

From this angle Deepanshu's patch [1] is correct.

Strictly speaking it's not a real bug though caught by syzbot. The logic
in batch_add_pfn_num() doesn't really care about the initial value of
batch->kind when the entire batch is empty:

        if (batch->kind != kind) {
                /* One kind per batch */
                if (batch->end != 0)
                        return false;
                batch->kind = kind;
        }

It works correctly even if batch->kind is uninitialized.

[1] https://lore.kernel.org/all/20260124132214.624041-1-kartikey406@gmail.com/

Re: [PATCH] iommufd: Initialize batch->kind field in pfn_batch

[Fushuai Wang]

> this is incorrect. 'carry' means a portion of previous batch was handed
> over to the new batch, and it already initializes the array with a valid
> item#0. So the old 'kind' type should be kept.

Yes, you are right.

> From this angle Deepanshu's patch [1] is correct.

I was not aware of Deepanshu's patch before, please ignore my patch.

---
Regards,
WANG