Re: [PATCH for-4.22 1/2] xen/arm: validate IRQs before descriptor lookup

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 7/10/26 1:48 PM, Mykola Kvach wrote:
> On Fri, Jul 10, 2026 at 12:44:44PM +0200, Orzel, Michal wrote:
> > On a tangent note:
> > I can see that you pushed quite a few "for-4.22" patches. We are approaching the
> > release, so afaict at this point we should only be taking crucial bug fixes.
> > Moreover, when sending "for-X" patches, please include a description with your
> > analyzed pros/cons of taking a patch in.
> Ack. I understand. For this patch specifically, I consider it a crucial
> fix for 4.22 for the following reasons:
>
> Pros:
> - It prevents an out-of-bounds irq_desc[] access which may corrupt Xen
>    memory or crash the hypervisor.
> - The issue was introduced by eSPI support already present in 4.22.
> - The change is small, and valid IRQ handling remains unchanged.
> - I tested CONFIG_GICV3_ESPI=y and CONFIG_GICV3_ESPI=n builds and
>    reproduced the issue on FVP using a fake DT interrupt with reserved
>    INTID 3000.
>
> Cons:
> - The trigger requires either a malformed DT interrupt specifier, such
>    as reserved INTID 3000, or an eSPI unsupported by the Xen build.
> - The demonstrated failure used deliberate fault injection rather than
>    a reported production failure.
> - The patch adds validation to common Arm IRQ setup paths, although
>    valid IRQs continue through the same path as before.
>
> Assessment:
> The hypervisor memory-safety impact and the presence of the affected
> eSPI code in 4.22 outweigh the limited regression risk.
>
> I will include this kind of pros/cons analysis with future for-X
> submissions.
It doesn't seem as critical. IIUC, exploiting this issue requires 
providing a malformed DT interrupt specifier. If the DT interrupt 
specifier is valid, the system should behave correctly.
Given that we are very close to the release, I think it would be better 
to proceed without these changes. If the issue proves to be critical, we 
can backport the fixes afterward.
~ Oleksii