Linux kernel ice: relaxed Tx doorbell write on arm64 trips a BUG_ON in dql_completed and panics the host

CVSS 7.5CVE-2026-98965Kernel, userspace & hypervisorcurated

Impact

The ice transmit path rings the hardware doorbell with writel_relaxed(), which on arm64 does not order the preceding update of dql->num_queued against the MMIO write. The NIC can start and finish transmitting before the queue accounting is globally visible, dql_completed() then sees more bytes completed than queued, and the kernel hits BUG_ON at lib/dynamic_queue_limits.c:99 - an immediate panic inside ice_napi_poll. The reporter reproduced this reliably on an arm64 machine with an Intel E810-XXV under sustained network load, and swapping writel() back in eliminated it. For operators this is an availability bug on arm64 GPU nodes (Grace, Altra, Graviton-class hosts) fitted with E810 NICs: a node that panics under heavy traffic takes its jobs with it, and a node that panics repeatedly under normal load is effectively out of the fleet. x86 hosts are not affected in practice because writel_relaxed there already carries the needed ordering. The regression was introduced by commit ccde82e90946, which changed the doorbell from writel() to writel_relaxed().

Who can reach it

No authentication and no attacker needed in the usual sense - it is a race that sustained Tx load triggers on its own. Anyone who can drive heavy outbound traffic through an affected arm64 node (a tenant workload, an all-reduce, a data loader) can make it more likely. Only arm64 hosts running the ice driver on E8xx-series NICs are exposed.

What to do

Take the stable kernel carrying the writel() restoration (three stable branches fixed) and reboot each affected arm64 node. There is no runtime workaround that keeps the fast path intact; reducing Tx load only lowers the probability. x86 fleets can deprioritize this entirely.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-98965 https://git.kernel.org/stable/c/7a579dec8423bba7bec96fcfcb2e30838b0858ee https://git.kernel.org/stable/c/f94ab1fffd009250d72c6dc1662cb84467ac5365

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.