---
id: "CVE-2026-98489"
kind: "vulnerability"
aliases: ["CVE-2026-98489"]
title: "Linux kernel atl1c driver: soft lockup on out-of-range tx completion index"
severity: "low"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["atl1c", "ethernet", "infrastructure", "kernel", "linux", "proxmox", "self-hosted"]
not_affected_if: ["no-atl1c-nic"]
published_at: "2026-10-18T16:16:59+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:25:45+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98489", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel atl1c driver: soft lockup on out-of-range tx completion index

The atl1c Ethernet driver for Qualcomm Atheros AR8151 NICs can spin forever in its transmit cleanup loop when the hardware reports an out-of-range completion index while the PCIe link resets. The result is a soft lockup that hangs a CPU; the sources describe a denial of service, not code execution.

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

## How to check

- Run `uname -r` and check whether the kernel predates the fix; the sources do not name the fixed kernel version.
- Run `lspci -nn | grep -i atheros` to see whether an AR8151 (atl1c) NIC is present.
- Run `lsmod | grep atl1c` to confirm the atl1c driver is loaded.
- Check `dmesg` for 'soft lockup' or 'atl1c' transmit timeout messages.

## Fix

- Update the Linux kernel to a release that includes the upstream atl1c fix (the sources do not list the exact version).
- Until patched, unknown mitigation; the sources do not say.

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98489

## From the sources

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

net: atl1c: fix soft lockup on out-of-range tpd_cons read

The hardware can report an out-of-range tpd_cons (seen as 0xffff)
while the PCIe link/MAC is resetting. An out-of-range value can
never be reached and the loop below would spin forever. To avoid
a soft lockup treat it as "nothing new to clean" instead.

Reproduced on two machines, same NIC (Qualcomm Atheros AR8151 v2.0,
4-port), triggered by rebooting a Mikrotik CCR2004 PCIe card that
the ports are directly linked to:

- Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic. The link-flap
  precursor, before the lockup was captured with a full trace
  elsewhere:

    atl1c 0000:05:00.0 enp5s0f0: NETDEV WATCHDOG: CPU: 4: transmit queue 2 timed out 489984 ms
    atl1c 0000:05:00.0: MAC state machine can't be idle since disabled for 10ms second
    atl1c 0000:05:00.0: atl1c: enp5s0f0 NIC Link is Up<65535 Mbps Full Duplex>

  65535 (0xffff) here is the same value tpd_cons reads back once the
  loop below gets stuck.

- Proxmox VE, kernel 7.0.14-11-pve. Same NIC/trigger, this time
  caught by the soft lockup watchdog with a full stack trace:

    watchdog: BUG: soft lockup - CPU#12 stuck for 354s! [napi/eth%d-0:329]
    CPU: 12 UID: 0 PID: 329 Comm: napi/eth%d-0 Tainted: P O L 7.0.14-11-pve #1 PREEMPT(lazy)
    RIP: 0010:atl1c_clean_tx+0x142/0x2d0 [atl1c]
    Call Trace:
     <TASK>
     __napi_poll+0x32/0x1e0
     napi_threaded_poll_loop+0x286/0x2e0
     napi_threaded_poll+0xfd/0x140
     kthread+0xf7/0x130
     ret_from_fork+0x2da/0x3a0
     ret_from_fork_asm+0x1a/0x30
     </TASK>

---

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