PT-2026-98683 · Linux · Linux

CVE-2026-98020

·

Published

2026-09-25

·

Updated

2026-09-25

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
pds core: fix cmd regs access racing BAR unmap on reset
pdsc reset prepare() and pdsc reset done()'s pdsc map bars() error path clear/iounmap cmd regs without devcmd lock, and pdsc legacy firmware update()'s download loop derefs cmd regs after dropping and retaking the lock without re-checking. An FLR concurrent with a devlink flash can unmap cmd regs under an in-flight devcmd, causing a NULL deref or a write to unmapped MMIO.
Take devcmd lock across the BAR unmap/remap, and re-check cmd regs in the download loop. Only the PF maps cmd regs and runs devcmd, so skip the unmap on a VF, as pdsc remove() and pdsc reset done() already do.
A reset that completes entirely within the unlocked window is not a correctness problem for the image: the device clears its update session, so a resumed download is rejected, and it verifies the staged image before writing a flash slot, reporting PDS RC BAD FW rather than activating it.
pdsc unmap bars() also clears info regs, intr status and intr ctrl. The interrupt and start/stop readers of those are quiesced before the unmap by pdsc fw down(), which frees the interrupts and tears down the queues. The debugfs readers are not, since those files outlive a reset; that is pre-existing and out of scope here.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98020

Affected Products

Linux