Re: [PATCH 2/9] iommu/io-pgtable: introduce iova_to_phys_length in io_pgtable_ops

[sashiko-bot@kernel.org]

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

New issues:
- [Critical] The `iova_to_phys_length` implementations return the total block/page size instead of the remaining mapped length, violating the API contract and risking out-of-bounds traversal.

Pre-existing issues:
- [High] Uninitialized stack variable usage in `arm_lpae_iova_to_phys_length` when `iova` is `ULONG_MAX`.
- [High] Data race and TOCTOU vulnerability due to unprotected double-reading of the PTE in the page table walk callback.
--

commit 3219288135ef40cd65a3a4a3c01d71fbe03eb398
Author: Guanghui Feng <guanghuifeng@linux.alibaba.com>
Subject: iommu/io-pgtable: introduce iova_to_phys_length in io_pgtable_ops

This patch adds iova_to_phys_length to struct io_pgtable_ops. The new
callback returns the mapped length from iova to the end of the mapping
entry through the mapped_length parameter, and is implemented for the
ARM LPAE, ARM v7s, and DART backends.

> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c

[ ... ]

> @@ -661,6 +673,11 @@ static phys_addr_t arm_v7s_iova_to_phys(struct io_pgtable_ops *ops,
>  	mask = ARM_V7S_LVL_MASK(lvl);
>  	if (arm_v7s_pte_is_cont(pte, lvl))
>  		mask *= ARM_V7S_CONT_PAGES;
> +
> +	blk_size = ~mask + 1U;
> +	if (mapped_length)
> +		*mapped_length = blk_size;

[Severity: Critical]
Does this return the total block size instead of the remaining mapped length?

The io_pgtable_ops documentation requires returning the remaining mapped length
from the iova to the end of the mapping entry. However, this seems to return
the full block size without subtracting the intra-block offset.

If a caller passes an unaligned iova and uses mapped_length to advance its
traversal iterator, could this cause it to overshoot the current block and
skip subsequent page table regions?

This same pattern appears to be used in the ARM LPAE and DART implementations
added in this patch as well.

> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c

[ ... ]

>  static int visit_iova_to_phys(struct io_pgtable_walk_data *walk_data, int lvl,
>  			      arm_lpae_iopte *ptep, size_t size)
>  {
>  	struct iova_to_phys_data *data = walk_data->data;
>  	data->pte = *ptep;

[Severity: High]
This isn't a bug introduced by this patch, but could this unprotected read
of *ptep lead to a torn read or a Time-of-Check to Time-of-Use issue?

The caller io_pgtable_visit() safely reads the PTE into a local variable
using READ_ONCE() to validate it, but passes the raw ptep pointer to this
callback.

If the PTE is modified concurrently between the READ_ONCE() in the caller
and the direct dereference here, could we end up with torn reads on 32-bit
ARM systems or return a garbage physical address translation?

>  	data->lvl = lvl;
>  	return 0;
>  }

[ ... ]

> +static phys_addr_t arm_lpae_iova_to_phys_length(struct io_pgtable_ops *ops,
> +						 unsigned long iova,
> +						 size_t *mapped_length)
>  {
>  	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
>  	struct iova_to_phys_data d;
>  	struct io_pgtable_walk_data walk_data = {
>  		.data = &d,
>  		.visit = visit_iova_to_phys,
>  		.addr = iova,
>  		.end = iova + 1,
>  	};

[Severity: High]
This is a pre-existing issue, but can walk_data.end overflow if iova is
ULONG_MAX?

If iova is ULONG_MAX, iova + 1 would wrap around to 0. During the walk in
__arm_lpae_iopte_walk(), the loop condition checks walk_data->addr <
walk_data->end. With end being 0, wouldn't this condition be immediately false?

If the walk returns 0 (success) without calling the visit callback, could we
end up using the uninitialized d.lvl and d.pte fields to compute block_size
and the physical address?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260531093637.3893199-1-guanghuifeng@linux.alibaba.com?part=2