CVE-2026-98489

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>