Cloudanix VulnDB

CVE-2026-68319

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake in a Linux driver can cause the computer to freeze when certain hardware is removed or reset.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Deadlock between pdsc_pci_reset_thread() holding workqueue context and pdsc_remove() waiting on device_lock, caused by pci_reset_function() acquiring the same lock while remove already holds it.

Why it matters to the business

Systems using the affected pds_core driver can experience kernel hangs or forced reboots during PCI device removal or reset operations, reducing availability of storage or network functions.

How an attack unfolds

An attacker with local access triggers concurrent PCI function reset and driver unbind/remove paths; the reset work item blocks on device_lock already held by remove, while remove blocks on workqueue destruction, resulting in deadlock.

How to fix it

Update the Linux kernel to a version containing the fix that replaces pci_reset_function with pci_try_reset_function and removes unnecessary pci_dev_get/put calls around the reset work item.

How to confirm the fix worked

Verify the running kernel source contains the commit that switches to pci_try_reset_function and destroys the driver workqueue before pdsc_remove returns; confirm no deadlock occurs under concurrent reset/remove test scenarios.

Typical attack path

  1. Obtain local access to trigger PCI device events
  2. Initiate pci_reset_function via driver interface
  3. Simultaneously trigger pdsc_remove through unbind or hot-unplug
  4. Workqueue blocks indefinitely waiting for contended lock

How to detect it

Review kernel logs for workqueue destruction timeouts or lockdep warnings involving device_lock and pdsc_remove; examine dmesg for pds_core reset thread stalls during PCI removal sequences.

What your security team should do

  • Prioritize kernel updates on systems exposing pds_core devices
  • Monitor for kernel hangs during PCI hotplug or reset events
  • Apply the patch or backport if custom kernels are in use

The record

In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.

Affected packages

Ecosystem Package Introduced Fixed