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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In pds_core, take devcmd_lock across BAR unmap/remap operations, re-check cmd_regs in pdsc_legacy_firmware_update()'s download loop after reacquiring the lock, and skip cmd_regs unmapping on a VF.
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.