Buffer overflow isn't the interesting part. What matters more is it's just wrong. There's no real security concern here. So I don't think it's helpful to highlight that as the first thing in the subject line (if at all; it can be mentioned as an aside in the body), as that's just going to make people think security issue.

The context is also worth adding: arm64 uses 10 cells per entry because its GIC node has #interrupt-cells = 3, but riscv uses 9 cells per entry because its APLIC node has #interrupt-cells = 2, and when the code was copied the fdt_property_placeholder call was updated accordingly along with removing the SET_PROP_U32 for that cell, but the stride was not updated.

In D61473#1408998, @jrtc27 wrote:

Buffer overflow isn't the interesting part. What matters more is it's just wrong. There's no real security concern here. So I don't think it's helpful to highlight that as the first thing in the subject line (if at all; it can be mentioned as an aside in the body), as that's just going to make people think security issue.

The context is also worth adding: arm64 uses 10 cells per entry because its GIC node has #interrupt-cells = 3, but riscv uses 9 cells per entry because its APLIC node has #interrupt-cells = 2, and when the code was copied the fdt_property_placeholder call was updated accordingly along with removing the SET_PROP_U32 for that cell, but the stride was not updated.

Thanks for taking a look. I have updated the title and commit description with context and incorrect entry stride.