Re: [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Off-by-one array bounds check in `get_shadow_interrupts()` allows out-of-bounds write.
- [High] Bitwise shift overflow and incorrect register targeting when unmasking CPU interrupts >= 32 in `econet_cpu_init()`.
--

--- Patch [2]: [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor ---
commit 2334c8459979130dce8cf68994de6842f0bba377
Author: Caleb James DeLisle <cjd@cjdns.fr>

mips: dts: econet: Describe dual-VPE 34Kc processor
    
The 34Kc processor has two VPEs (threads) and the interrupt controller
on the EN751221 re-routes (in hardware) the software interrupt pins
zero and one to numbers 7 and 8 in the flat VEIC interrupt domain.

> diff --git a/arch/mips/boot/dts/econet/en751221.dtsi b/arch/mips/boot/dts/econet/en751221.dtsi
> index 72cb65654c341..57ae84a8a9f85 100644
> --- a/arch/mips/boot/dts/econet/en751221.dtsi
> +++ b/arch/mips/boot/dts/econet/en751221.dtsi

[ ... ]

> @@ -65,6 +71,7 @@ intc: interrupt-controller@1fb40000 {
>  		interrupt-controller;
>  		#interrupt-cells = <1>;
>  		econet,shadow-interrupts = <7 2>, <8 3>, <13 12>, <30 29>;

[Severity: High]
This isn't a bug introduced by this patch, but is there an off-by-one array
bounds check in the driver that parses this property?

Looking at get_shadow_interrupts() in drivers/irqchip/irq-econet-en751221.c,
the bounds check uses > instead of >=:

    if (shadow > IRQ_COUNT) {
        ...

If a device tree supplies a shadow interrupt number of 40 (which equals
IRQ_COUNT), this check evaluates to false. This allows an out-of-bounds
write of one byte past the end of the econet_intc struct:

    econet_intc.interrupt_shadows[shadow] = IS_SHADOW;

Could this lead to adjacent memory corruption if malformed device tree data
is parsed?

> +		econet,cpu-interrupt-map = <7 0>, <8 1>;

[Severity: High]
This is a pre-existing issue, but does parsing this property expose a bitwise
shift overflow and incorrect register targeting in the driver if receive
IRQs >= 32 are provided?

In drivers/irqchip/irq-econet-en751221.c:econet_cpu_init(), the code validates
input up to IRQ_COUNT - 1 (39), but unconditionally applies BIT(receive) to a
32-bit mask:

    mask |= BIT(receive);

It then writes this to REG_MASK0, which is only for IRQs 0-31, ignoring
REG_MASK1:

    econet_wreg(REG_MASK0, mask, mask);

Since the driver explicitly validates input up to 39, could providing a device
tree with receive IRQs >= 32 trigger undefined behavior and functional failures?

>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728184959.102441-1-cjd@cjdns.fr?part=2