CVE-2026-98020: pds_core: fix cmd_regs access racing BAR unmap on reset
In the Linux kernel, the following vulnerability has been resolved:
pdscore: fix cmdregs access racing BAR unmap on reset
pdscresetprepare() and pdscresetdone()'s pdscmapbars() error path clear/iounmap cmdregs without devcmdlock, and pdsclegacyfirmwareupdate()'s download loop derefs cmdregs after dropping and retaking the lock without re-checking. An FLR concurrent with a devlink flash can unmap cmdregs under an in-flight devcmd, causing a NULL deref or a write to unmapped MMIO.
Take devcmdlock across the BAR unmap/remap, and re-check cmdregs in the download loop. Only the PF maps cmdregs and runs devcmd, so skip the unmap on a VF, as pdscremove() and pdscresetdone() 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 PDSRCBADFW rather than activating it.
pdscunmapbars() also clears inforegs, intrstatus and intrctrl. The interrupt and start/stop readers of those are quiesced before the unmap by pdscfwdown(), 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race?
Only Physical Function (PF) instances are exposed, because only the PF maps cmd_regs and issues device commands. Virtual Function (VF) instances do not need the BAR unmap path involved in the race.
What concurrent activity is required to trigger the issue?
A function-level reset (FLR) must occur while a devlink firmware flash operation is in progress. The race can unmap cmd_regs while an in-flight device command or resumed firmware-download loop accesses it, leading to a NULL dereference or writes to unmapped MMIO.
Could an interrupted firmware update activate a bad image?
A reset during the unlocked window does not cause an invalid image to be activated. The device clears the update session, rejects a resumed download, and verifies the staged image before writing a flash slot; it reports PDS_RC_BAD_FW rather than activating a bad image.