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

[Mykola Kvach <xakep.amatop@xxxxxxxxx>]

Hi Oleksii,

Thank you for the review.

On Mon, Jul 13, 2026 at 10:39 AM Oleksii Kurochko
<oleksii.kurochko@xxxxxxxxx> wrote:
>
>
>
> 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.

Okay, thanks.

What do you think about the second patch in this series? I believe it
is more critical. Unlike the first issue, it can be triggered with a
valid eSPI configuration: freeing a valid eSPI uses the raw INTID as
the bitmap index, causing an out-of-bounds access that may corrupt
memory.

Could it still be considered for 4.22?

Best regards,
Mykola