Look up another CVE · open CVE-2026-64148 in the interactive tracker
CVE-2026-64148
pds_core: fix error handling in pdsc_devcmd_wait
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64148 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Fix two cases where pdsc_devcmd_wait() returns stale success from the completion register instead of an error: 1. FW crash: If firmware stops running, the wait loop breaks early with running=false. The condition "if ((!done || timeout) && running)" is false, so error handling is bypassed and stale status is returned. Check !running first and return -ENXIO. 2. Timeout: If a command times out, err is set to -ETIMEDOUT but then overwritten by pdsc_err_to_errno(status) which reads stale status. Return -ETIMEDOUT immediately after cleaning up. Both errors now propagate to pdsc_devcmd_locked() which queues health_work for recovery.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/amd/pds_core/dev.c
- What this is
- AMD PDS CORE DRIVERMAINTAINERS section matched on drivers/net/ethernet/amd/pds_core/ · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_NET_VENDOR_AMD|CONFIG_PDS_CORE' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code in 3 releases. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixie, forky, sidn
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_ETHERNET, CONFIG_NET_VENDOR_AMD, CONFIG_PDS_CORE
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.47%, higher than 39.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.4 | 6.6.142 | 3231aff8ab26 |
| 6.4 | 6.12.92 | 10ae3180095b |
| 6.4 | 6.18.34 | 784dd2bdc622 |
| 6.4 | 7.0.11 | 560d55932416 |
| 6.4 | 7.1 | 0e46b6635b03 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The vulnerable code is in the AMD/Pensando pds_core host driver for a network DPU/NIC whose firmware processes remote traffic; a remote attacker can crash or hang firmware via crafted packets, which drives kernel recovery through pdsc_devcmd_locked() during pdsc_fw_up/pdsc_setup.
- AC:LAttack complexity, low
- Once the device is reachable, an attacker can reliably induce the triggering conditions (firmware crash or devcmd timeout) by sending concurrent or malformed network traffic to stress the DPU firmware, without depending on uncontrollable timing or memory layout.
- PR:NPrivileges required, none
- Exploitation does not require host credentials; an unauthenticated remote attacker who can send traffic to the Pensando DSC interface can cause firmware failure that reaches pdsc_devcmd_wait() during automatic driver recovery, independent of devlink or root-only management paths.
- UI:NUser interaction, none
- No victim interaction is required beyond normal network connectivity to the affected DPU-backed host; recovery is triggered automatically by firmware failure and the driver's health/recovery workqueue path.
- S:UScope, unchanged
- The flaw affects host kernel driver state and device recovery within the same security authority; it does not cross a VM, container, or IOMMU boundary to impact a separate security domain.
- C:NConfidentiality impact, none
- The bug is a logic error returning stale MMIO completion status rather than a memory-safety flaw; it does not expose arbitrary kernel memory, only misinterprets bounded device register contents from prior commands.
- I:NIntegrity impact, none
- There is no kernel memory corruption or arbitrary write primitive; the worst case is proceeding with stale device-command completion data, which affects driver/device recovery state rather than modifying protected host data.
- A:HAvailability impact, high
- Masking firmware crash or timeout as success prevents immediate health_work recovery, can leave the driver believing a failed INIT/reset succeeded, and can cause prolonged or repeated loss of DPU/network availability on internet-facing cloud servers until manual intervention or repeated recovery cycles.