UBUNTU-CVE-2026-98020: Medium severity ubuntu/linux-hwe-edge vulnerability
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
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, skip cmd_regs BAR unmapping on VFs; hold devcmd_lock across BAR unmap/remap in pdsc_reset_prepare() and pdsc_reset_done()'s pdsc_map_bars() error path; and re-check cmd_regs in pdsc_legacy_firmware_update()'s download loop after reacquiring the lock.
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
The affected path is limited to physical functions (PFs), because only PFs map cmd_regs and issue device commands. Virtual functions (VFs) skip the relevant BAR unmap path.
What condition is required to trigger the issue?
A function-level reset (FLR) must occur concurrently with a devlink firmware flash operation while a device command is in flight. The reset can unmap cmd_regs during that command or while the firmware download loop resumes.
What could happen if the race is triggered?
The driver can dereference a NULL cmd_regs pointer or write to unmapped MMIO. A reset during a firmware download does not cause an incomplete image to be activated: the device clears the update session, rejects the resumed download, and verifies the staged image before writing a flash slot.
What can be done before an update is available?
Avoid performing devlink firmware flash operations at the same time as FLRs or other activity that can reset the device. This reduces the concurrent reset-and-download condition required for the race.