The original patch combined the generic IORT node walk with the
IOMMU-specific RMR descriptor and ID-mapping arrays.  This version
separates those contracts as requested.

Patch 1 validates the root node area, complete node headers and advertised
node lengths in each generic walker.  Patch 2, built only with
CONFIG_IOMMU_API, validates the fixed RMR payload and both arrays before
walking them.

Changes since v1:
https://lore.kernel.org/all/20260706094300.82618-1-pengpeng@iscas.ac.cn/
- split generic traversal from RMR array validation
- validate root node_offset and node_count before pointer construction
- scope RMR helpers with their CONFIG_IOMMU_API users
- document why a zero-count array needs no offset validation

Testing used Linux 3d6d817622b0 plus this series, GCC 13.3 and QEMU
8.2.2 with a Cortex-A57 arm64 CPU model.  A temporary KUnit harness in
iort.c called the actual static validation helpers; the harness is not
part of this series.  The acpi_iort_bounds suite passed both tests,
covering invalid root offsets, truncated node and RMR payload extents,
and out-of-bounds RMR descriptor and ID-mapping arrays.

This did not exercise a platform-provided IORT table through the complete
boot-time discovery path.

Pengpeng Hou (2):
  ACPI: IORT: validate table and node extents before traversal
  ACPI: IORT: validate RMR node array extents

 drivers/acpi/arm64/iort.c | 117 +++++++++++++++++++++++++++++++++++---
 1 file changed, 109 insertions(+), 8 deletions(-)


base-commit: 3d6d817622b0a9721e3cc404df3469171582be13
-- 
2.50.1 (Apple Git-155)

On 13/08/2026 5:01 pm, Pengpeng Hou wrote:
> The original patch combined the generic IORT node walk with the
> IOMMU-specific RMR descriptor and ID-mapping arrays.  This version
> separates those contracts as requested.
> 
> Patch 1 validates the root node area, complete node headers and advertised
> node lengths in each generic walker.  Patch 2, built only with
> CONFIG_IOMMU_API, validates the fixed RMR payload and both arrays before
> walking them.

But why? If a platform really did have an IORT that's so obviously 
malformed or corrupted, why would we assume that all its other ACPI 
tables are valid enough to even be able to boot as far as running this 
code? Or conversely, what if the table does happen to have the correct 
structure but is still full of nonsense such that we end up exploding 
later when a driver touches bogus iomem?

Mainline Linux is not a firmware validation suite; if we can't assume 
basic stuff like table headers are correct then there's basically not 
much point in even trying. Also it is highly unlikely that people who 
write firmware would ship it without doing any testing; if Linux crashes 
horribly the first time they try to boot their new build, they're 
probably going to notice that something's wrong. However, from 
experience, if Linux does successfully boot to a shell then they may 
assume it's fine and ship it even if the IORT node ID mapping offsets 
are bogus so MSIs don't work and devices have fallen back to legacy 
interrupts...

Thus if anything there's an argument to be made that the more we try to 
be robust against unreasonably broken firmware, the more unreasonably 
broken firmware will propagate into the wild. And if you think people 
will care about kernel warnings, try looking at the boot logs of just 
about any production Android device ;)

Thanks,
Robin.

> 
> Changes since v1:
> https://lore.kernel.org/all/20260706094300.82618-1-pengpeng@iscas.ac.cn/
> - split generic traversal from RMR array validation
> - validate root node_offset and node_count before pointer construction
> - scope RMR helpers with their CONFIG_IOMMU_API users
> - document why a zero-count array needs no offset validation
> 
> Testing used Linux 3d6d817622b0 plus this series, GCC 13.3 and QEMU
> 8.2.2 with a Cortex-A57 arm64 CPU model.  A temporary KUnit harness in
> iort.c called the actual static validation helpers; the harness is not
> part of this series.  The acpi_iort_bounds suite passed both tests,
> covering invalid root offsets, truncated node and RMR payload extents,
> and out-of-bounds RMR descriptor and ID-mapping arrays.
> 
> This did not exercise a platform-provided IORT table through the complete
> boot-time discovery path.
> 
> Pengpeng Hou (2):
>    ACPI: IORT: validate table and node extents before traversal
>    ACPI: IORT: validate RMR node array extents
> 
>   drivers/acpi/arm64/iort.c | 117 +++++++++++++++++++++++++++++++++++---
>   1 file changed, 109 insertions(+), 8 deletions(-)
> 
> 
> base-commit: 3d6d817622b0a9721e3cc404df3469171582be13