---
id: "CVE-2026-98965"
kind: "vulnerability"
aliases: ["CVE-2026-98965"]
title: "Linux kernel: Intel E810 driver race can crash arm64 hosts under load"
severity: "unknown"
cvss: null
epss: 0.00206
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["arm64", "ice-driver", "infrastructure", "intel-e810", "linux-kernel"]
not_affected_if: ["no-e810-hardware"]
published_at: "2026-10-23T13:17:17+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98965", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98965", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: Intel E810 driver race can crash arm64 hosts under load

The ice network driver for Intel E810 adapters used a relaxed MMIO write for the transmit doorbell, so on arm64 the NIC could start sending before queue accounting was visible. The accounting check then hits a BUG_ON and crashes the kernel, a denial of service rather than code execution.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the kernel build that carries the upstream ice fix
- `lspci | grep -i e810` to confirm an Intel E810 controller is present
- `uname -m` to confirm the host is arm64 (aarch64)

## Fix

- Update the Linux kernel to a release that includes the upstream fix restoring writel() in the ice Tx doorbell path (version unknown from sources)
- Until patched, unknown workaround from sources

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98965
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98965

## From the sources

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

ice: Restore Ordered MMIO Writes for Tx Doorbells

The DQL accounting state which tracks the number of bytes queued for the
NIC to transmit, namely dql->num_queued, is updated by the ICE driver
when it invokes __netdev_tx_sent_queue(). Subsequently the driver
updates the hardware queue tail allowing the NIC to begin processing the
work queue. The queue accounting update should be ordered before the NIC
begins transmitting descriptors.

The transmit path currently updates the hardware doorbell using
writel_relaxed(), which (on arm64) does not provide the same ordering
guarantees between writes to normal memory and writes to MMIO registers
that writel() does. This introduces a potential race where the NIC
begins transmitting descriptors before the dql->num_queued update is
globally visible. If the NIC finishes before the update is observed by
dql_completed(), it detects an invalid state where more bytes have been
completed than have been queued. When this happens the following BUG_ON
is triggered.

  BUG_ON(count > num_queued - dql->num_completed);

This has been observed and manifests as the following crash (note that
the trace has been trimmed) in an environment with sustained network
load that uses an Intel Corporation Ethernet Controller E810-XXV for SFP
(rev 02) on an arm64 machine. Replacing writel_relaxed() with writel()
in a test kernel eliminated the crash in the user's workload, which
previously reproduced the issue reliably.

  kernel BUG at lib/dynamic_queue_limits.c:99

Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
pc : dql_completed+0x268/0x2a0
lr : ice_clean_tx_irq+0x1d4/0x620 [ice]
Call trace:
dql_completed+0x268/0x2a0 (P)
ice_napi_poll+0x94/0x520 [ice]
__napi_poll+0x48/0x3f0
net_rx_action+0x194/0x420

This restores the behaviour prior to commit ccde82e90946 ("ice: add E830
Earliest TxTime First Offload support"), which changed the notification
mechanism from writel() to writel_relaxed().

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_