CVE-2024-35968: pds_core: Fix pdsc_check_pci_health function to use work thread
In the Linux kernel, the following vulnerability has been resolved:
pds_core: Fix pdsc_check_pci_health function to use work thread
When the driver notices fw_status == 0xff it tries to perform a PCI
reset on itself via pci_reset_function() in the context of the driver's
health thread. However, pdsc_reset_prepare calls
pdsc_stop_health_thread(), which attempts to stop/flush the health
thread. This results in a deadlock because the stop/flush will never
complete since the driver called pci_reset_function() from the health
thread context. Fix by changing the pdsc_check_pci_health_function()
to queue a newly introduced pdsc_pci_reset_thread() on the pdsc's
work queue.
Unloading the driver in the fw_down/dead state uncovered another issue,
which can be seen in the following trace:
WARNING: CPU: 51 PID: 6914 at kernel/workqueue.c:1450 __queue_work+0x358/0x440
[...]
RIP: 0010:__queue_work+0x358/0x440
[...]
Call Trace:
<TASK>
? __warn+0x85/0x140
? __queue_work+0x358/0x440
? report_bug+0xfc/0x1e0
? handle_bug+0x3f/0x70
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? __queue_work+0x358/0x440
queue_work_on+0x28/0x30
pdsc_devcmd_locked+0x96/0xe0 [pds_core]
pdsc_devcmd_reset+0x71/0xb0 [pds_core]
pdsc_teardown+0x51/0xe0 [pds_core]
pdsc_remove+0x106/0x200 [pds_core]
pci_device_remove+0x37/0xc0
device_release_driver_internal+0xae/0x140
driver_detach+0x48/0x90
bus_remove_driver+0x6d/0xf0
pci_unregister_driver+0x2e/0xa0
pdsc_cleanup_module+0x10/0x780 [pds_core]
__x64_sys_delete_module+0x142/0x2b0
? syscall_trace_enter.isra.18+0x126/0x1a0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7fbd9d03a14b
[...]
Fix this by preventing the devcmd reset if the FW is not running.
Security readout for executives and security teams
Plain-English summary
A Linux pds_core network driver fault can deadlock during PCI recovery when firmware becomes unresponsive. Driver removal in the same firmware state can also improperly queue reset work. Affected systems may hang or lose reliable device operation. The supplied rating is high, although the public description does not establish how confidentiality or integrity compromise would occur.
Executive priority
Treat as a high-priority reliability and security update for systems actively using pds_core, especially critical network infrastructure. Systems without that driver or associated hardware are less likely to be exposed. Patch through normal vendor channels after confirming applicability; there is no supplied evidence requiring emergency incident response for active exploitation.
Technical view
When firmware status becomes 0xff, the health thread calls pci_reset_function(). Reset preparation then stops and flushes that same thread, causing a self-deadlock. The correction moves PCI reset handling onto the driver's work queue. It also suppresses a device-command reset during teardown when firmware is not running, preventing invalid workqueue activity.
Likely exposure
Exposure requires an affected Linux kernel and use of the pds_core PCI driver. The supplied record identifies the affected line as beginning with Linux 6.7 and includes 6.8.7 and 6.9 boundary information, but its compact version data is ambiguous. Confirm exact vulnerable ranges against the linked stable commits or distribution advisories.
Exploitation context
The CVSS vector describes local access with low privileges, no user interaction, and high potential confidentiality, integrity, and availability impact. However, the supplied sources provide no exploit method or evidence of exploitation in the wild, and the CVE is not listed as KEV. The documented trigger involves failed firmware and driver reset or removal paths.
Researcher notes
The disclosed failure is a re-entrant thread shutdown deadlock plus unsafe reset work during teardown when firmware is down. The fixes separate reset execution from the health thread and gate reset commands on firmware state. The 7.8 CVSS claims high CIA impact, but the supplied narrative chiefly substantiates availability effects; no exploitation primitive or data-impact mechanism is described.
Mitigation direction
Install a vendor-supported kernel containing the linked stable fixes.
Prioritize systems that load pds_core and rely on its attached PCI hardware.
Consult distribution or appliance advisories for exact fixed package versions.
Avoid unsupported kernel downgrades or improvised driver changes.
Validation and detection
Record the running kernel and installed vendor package versions.
Check whether pds_core is present, loaded, or bound to PCI hardware.
Compare kernel sources or package changelogs with both linked fixes.
Review logs for firmware-down events, reset hangs, or workqueue warnings.
Retest device recovery and driver removal after the approved update.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35968 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.