In the Linux kernel, the following vulnerability has been resolved:

accel/ethosu: fix IFM region index out-of-bounds in command stream parser

NPUSETIFMREGION extracts the region index with param & 0x7f, giving a maximum value of 127. However regionsize[] and outputregion[] in struct ethosuvalidatedcmdstreaminfo are both sized to NPUBASEPREGIONMAX (8), giving valid indices [0..7].

Every other region assignment in the same switch uses param & 0x7: NPUSETOFMREGION: st.ofm.region = param & 0x7; NPUSETIFM2REGION: st.ifm2.region = param & 0x7; NPUSETWEIGHTREGION: st.weight[0].region = param & 0x7; NPUSETSCALEREGION: st.scale[0].region = param & 0x7;

The 0x7f mask on IFM is inconsistent and appears to be a typo.

featmatrixlength() and calcsizes() use the region index directly as an array subscript into the kzalloc'd info struct: info->regionsize[fm->region] = max(...);

A userspace caller supplying NPUSETIFMREGION with param > 7 causes a write up to 1278 = 1016 bytes past the start of regionsize[], corrupting adjacent kernel heap data.

Fix by applying the same & 0x7 mask used by all other region assignments.

In the Linux kernel, the following vulnerability has been resolved:

accel/ethosu: fix arithmetic issues in dmalength()

dmalength() derives DMA region usage from command stream values and updates regionsize[]:

len = ((len + stride[0]) size0 + stride[1]) size1 regionsize[region] = max(..., len + dma->offset)

Several arithmetic issues can corrupt the derived region size:

- signed stride values may underflow when added to len - intermediate multiplications may overflow - len + dma->offset may overflow during regionsize updates - dmalength() error returns were not validated by the caller

regionsize[] is later used by ethosujob.c to validate command stream accesses against GEM buffer sizes. Arithmetic wraparound can therefore under-report region usage and bypass the bounds validation.

Fix by validating signed additions, using overflow helpers for multiplications and offset updates, and propagating dmalength() failures to the caller.

In the Linux kernel, the following vulnerability has been resolved:

accel/ethosu: reject DMA commands with uninitialized length

cmdstateinit() initializes the command state with memset(0xff), leaving dma->len at U64MAX to signal missing setup. The only setter is NPUSETDMA0LEN; if userspace omits this command and issues NPUOPDMASTART, dma->len remains U64MAX.

In dmalength(), a positive stride added to U64MAX wraps to a small value. With size0 == 1, checkmuloverflow() does not trigger and dmalength() returns 0 instead of U64MAX. The caller's U64MAX check then passes, regionsize[] stays 0, and the bounds check in ethosujob.c is bypassed, allowing hardware to execute DMA with stale physical addresses.

Fix by checking for U64MAX at the start of dmalength() before any arithmetic, consistent with the sentinel value used throughout the driver to detect uninitialized fields.