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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

Hello Mykola,

On 7/13/26 12:46 PM, Mykola Kvach wrote:
> 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?
I agree that the second patch is more critical, but I don't think it 
should block the release. It would be good to include if possible, but I 
don't see it as a release blocker.
Maintainers, what do you think about taking the second patch for this 
release?
~ Oleksii