CVE-2026-98143: accel: ethosu: Don't read the U65 rounding mode as a storage mode
In the Linux kernel, the following vulnerability has been resolved:
accel: ethosu: Don't read the U65 rounding mode as a storage mode
Bits 15:14 of NPUSET{IFM,OFM}PRECISION select the activation storage mode on U85 only. On U65 the same field holds the rounding mode, and the command stream parser has read it as a storage mode since the driver was added.
That went unnoticed while unknown values fell through the switch, but now that they are rejected, every U65 command stream that asks for natural rounding (2) fails CMDSTREAMBOCREATE with -EINVAL. Mesa emits it for average pooling, concatenation, split, unpack, strided slice, LUT and argmax, which is 72 failures of the Teflon test suite on an i.MX93. Truncating rounding (1) is misread as well: it picks the two-tile address path and computes a bogus feature map size from tile bases the command stream never set.
Read the field as a storage mode only on the hardware where it is one.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue affects Linux systems using the Ethos-U driver with U65 hardware. The precision-field interpretation differs on U85, where those bits do select activation storage mode.
What workload behavior can reveal that a U65 system is affected?
U65 command streams requesting natural rounding can fail CMDSTREAM_BO_CREATE with -EINVAL. Mesa emits natural rounding for average pooling, concatenation, split, unpack, strided slice, LUT, and argmax operations.
What happens when truncating rounding is used on U65?
Truncating rounding is also misread as a storage mode. It can select a two-tile address path and calculate an invalid feature-map size from tile-base values that the command stream did not set.