CVE-2026-68319: Linux Kernel Race Condition Vulnerability

CVE-2026-68319 Overview

CVE-2026-68319 is a deadlock vulnerability in the Linux kernel's pds_core driver, which supports AMD Pensando Distributed Services devices. The flaw occurs between the driver's reset thread and its remove path during PCI device unbind operations. When pdsc_pci_reset_thread() runs concurrently with pdsc_remove(), both paths contend for the device lock held by the PCI core, causing the kernel thread to hang indefinitely. Kernel maintainers have committed a fix that replaces the blocking reset call with a non-blocking variant. The issue was published to the National Vulnerability Database (NVD) on August 10, 2026.

Critical Impact
Concurrent execution of the pds_core reset thread and device removal can deadlock the kernel, blocking PCI unbind and requiring a system reboot to recover.

Affected Products

Linux kernel builds shipping the pds_core driver prior to the fix commits
Systems using AMD Pensando Distributed Services (PDS) network devices
Distributions consuming the affected stable kernel branches

Discovery Timeline

2026-08-10 - CVE-2026-68319 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-68319

Vulnerability Analysis

The vulnerability is a deadlock (a race-condition class defect) between two kernel execution contexts in the pds_core PCI driver. The PCI core invokes pdsc_remove() with the per-device device_lock already held. If a reset work item scheduled on the driver's workqueue is already running as pdsc_pci_reset_thread(), that thread calls pci_reset_function(), which itself attempts to acquire device_lock before performing the reset.

The removal path calls destroy_workqueue() to tear down the driver's workqueue. destroy_workqueue() blocks until all pending and running work items complete. However, the running reset work item is itself blocked waiting for the device_lock that pdsc_remove() holds. Neither side can make progress, and the kernel task hangs. Recovery typically requires a reboot.

Root Cause

The root cause is the use of the blocking helper pci_reset_function() inside a workqueue item whose completion is a prerequisite for the remove path to proceed. Because pdsc_remove() runs under device_lock and must wait for the workqueue to drain, any reset work that also needs device_lock produces a circular wait. The pci_dev_get/pci_dev_put reference counting used around the work submission did not prevent this ordering problem.

Attack Vector

Triggering the deadlock requires a reset event to be in flight on the pds_core device at the same moment the driver is unbound or the device is removed. Reset events can arise from device error recovery, administrative reset via sysfs, or PCI hotplug. A local administrator with the ability to initiate device reset and unbind can reproduce the condition; the flaw is not remotely reachable. The impact is availability: kernel task hang and blocked device teardown.

See the upstream fix commits for details:

Detection Methods for CVE-2026-68319

Indicators of Compromise

Kernel task hang warnings referencing pdsc_remove, pdsc_pci_reset_thread, or destroy_workqueue in dmesg or /var/log/messages.
hung_task_timeout_secs messages showing tasks blocked on device_lock during PCI unbind of a pds_core device.
PCI unbind or driver rmmod operations that never return and leave a device in an unusable state until reboot.

Detection Strategies

Inventory running kernels and match the pds_core module version against the fixed stable commits listed above.
Enable CONFIG_DETECT_HUNG_TASK and forward kernel logs to a centralized log store to surface deadlock stack traces.
Correlate PCI reset events (sysfs reset writes, AER recovery) with subsequent driver unbind or removal actions on hosts running pds_core.

Monitoring Recommendations

Alert on kernel INFO: task ... blocked for more than N seconds messages that reference the pds_core driver symbols.
Track uptime and forced reboots on servers using AMD Pensando devices, since recovery from this deadlock typically requires a reboot.
Ingest dmesg and journal data into a centralized analytics platform to correlate hang traces across the fleet.

How to Mitigate CVE-2026-68319

Immediate Actions Required

Update to a Linux kernel that includes the pds_core fix commits referenced above from git.kernel.org.
Track distribution security advisories for backported patches to the enterprise kernels in use.
Avoid concurrent administrative operations that reset and unbind pds_core devices until the patched kernel is deployed.

Patch Information

The fix replaces pci_reset_function() with pci_try_reset_function(), which internally uses pci_dev_trylock() to acquire both the device lock and the PCI config access lock without blocking. If either lock is contended, the call returns -EAGAIN immediately, breaking the circular wait. The unnecessary pci_dev_get/pci_dev_put calls are removed because the driver-owned workqueue is destroyed in pdsc_remove(), which guarantees the work completes before remove returns, and the PCI core already holds a reference to the pci_dev throughout the unbind sequence. Apply the fix by upgrading to a kernel containing commits 19ef775c91c6, 54f905821f26, 90d9f3ef2884, or ab0eec0ff0a4.

Workarounds

Do not initiate manual PCI resets on pds_core devices while an unbind, rmmod, or hot-remove operation is pending.
Where possible, quiesce workloads on affected devices before triggering resets so no reset work items are in flight during teardown.
Schedule host reboots as the recovery path if a deadlock is observed, since the hung task cannot be cleared at runtime.