CVE-2026-97412: pds_core: quiesce DMA before freeing resources

Published Sep 24, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

pdscore: quiesce DMA before freeing resources

pdscteardown() frees DMA buffers but does not disable bus mastering, leaving the device able to perform DMA after the buffers are freed. This can lead to use-after-free if the device writes to freed memory.

Add pciclearmaster() to pdscteardown() to disable bus mastering before freeing resources, ensuring all DMA is quiesced.

Add pcisetmaster() to pdscsetup() to re-enable bus mastering, which is needed for the firmware recovery path since pdscteardown() now disables it.

Affected Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Compensating control

    In the pds_core driver, call pci_clear_master() in pdsc_teardown() before freeing DMA resources to quiesce DMA, and call pci_set_master() in pdsc_setup() to re-enable bus mastering.

Event History

Sep 24, 2026
CVE Published
via MITRE·04:03 PM
Data Sourced
via MITRE·04:03 PM
Description
Data Sourced
via NVD·05:17 PM
Description

Frequently Asked Questions

1

What systems are exposed to this issue?

Systems using the Linux kernel pds_core driver are exposed when the driver tears down device resources while the device can still perform DMA. The affected condition is specifically the teardown path that frees DMA buffers without first disabling PCI bus mastering.

2

What must occur for the use-after-free condition to arise?

The device must perform a DMA write after pdsc_teardown() has freed its DMA buffers. Because bus mastering remains enabled in the vulnerable behavior, the device can write to memory that has already been freed.

3

What does the fix change, and are there operational considerations?

The fix disables PCI bus mastering with pci_clear_master() before DMA resources are freed, quiescing DMA during teardown. It also re-enables bus mastering with pci_set_master() during setup because the firmware recovery path requires it.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203