linux-kernel - RE: [PATCH] iommufd: Initialize batch->kind field in pfn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB527624911E329D4B870380418C93A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 26 Jan 2026 07:55:07 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Fushuai Wang <fushuai.wang@...ux.dev>, "jgg@...pe.ca" <jgg@...pe.ca>,
	"joro@...tes.org" <joro@...tes.org>, "will@...nel.org" <will@...nel.org>,
	"robin.murphy@....com" <robin.murphy@....com>, "nicolinc@...dia.com"
	<nicolinc@...dia.com>
CC: "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"wangfushuai@...du.com" <wangfushuai@...du.com>,
	"syzbot+a0c841e02f328005bbcc@...kaller.appspotmail.com"
	<syzbot+a0c841e02f328005bbcc@...kaller.appspotmail.com>
Subject: RE: [PATCH] iommufd: Initialize batch->kind field in pfn_batch

> From: Fushuai Wang <fushuai.wang@...ux.dev>
> Sent: Monday, January 26, 2026 11:25 AM
> 
> From: Fushuai Wang <wangfushuai@...du.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@...kaller.appspotmail.com
> Closes:
> https://lore.kernel.org/all/6975b1f4.a00a0220.33ccc7.001f.GAE@google.co
> m/T/
> Signed-off-by: Fushuai Wang <wangfushuai@...du.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/