CVE-2026-68317 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
pds_core: fix auxiliary device add/del races
Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's
pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly.
add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer.
Check and update the slot under config_lock in both paths.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability identified in the Linux kernel represents a critical race condition affecting the pds_core subsystem within the network virtualization framework. This flaw manifests in the concurrent management of auxiliary device slots through the pf->vfs[vf_id].padev structure, where multiple execution paths attempt to manipulate the same resource simultaneously. The vulnerability stems from inadequate synchronization mechanisms that fail to properly protect shared data structures during concurrent access scenarios.
The technical implementation of this race condition occurs through two distinct code paths that operate on the same underlying slot structure. The first path originates from the VF's pdsc_reset_done() function, while the second path emerges from the PF's devlink enable_vnet/disable_vnet handler functions. Both paths utilize config_lock for serialization but demonstrate a fundamental flaw in their protective scope. The add() operation fails to validate whether a slot is already populated before registering a new auxiliary device, creating a resource leak scenario where the initial device registration remains unreferenced and orphaned in memory. Conversely, the del() operation performs its slot validation check outside the protection of config_lock, allowing for simultaneous deletion attempts that can result in double-free conditions.
The operational impact of this vulnerability extends beyond simple resource leakage to encompass potential system instability and security implications. When two concurrent delete operations execute simultaneously, the first operation successfully clears the slot structure while the second attempt dereferences a NULL pointer, leading to potential kernel crashes or memory corruption. This type of race condition represents a classic example of improper locking protocol where the critical section protection does not encompass all necessary operations, creating a window for concurrent access violations. The vulnerability directly aligns with CWE-362, which describes a Race Condition vulnerability, and falls under ATT&CK technique T1068, representing privilege escalation through kernel exploitation.
The remediation approach requires implementing comprehensive locking mechanisms that ensure all slot validation and modification operations occur within the protection of config_lock. This involves restructuring both the add() and del() paths to perform complete slot checking and updating operations while maintaining exclusive access to the shared resource. The fix ensures atomicity in slot management by preventing concurrent modifications to the pf->vfs[vf_id].padev structure, thereby eliminating both the device leak scenario and the NULL pointer dereference condition. This solution addresses the fundamental synchronization issue that allowed multiple threads to access the same slot structure without proper mutual exclusion, effectively closing the race condition window that previously enabled malicious or accidental concurrent access patterns.
The vulnerability demonstrates the complexity of kernel-level synchronization in virtualized environments where multiple subsystems must coordinate access to shared hardware resources through auxiliary device management. Proper implementation requires careful consideration of all code paths that interact with shared state, ensuring that every modification operation maintains data integrity even under concurrent access conditions. This fix exemplifies the importance of comprehensive lock scope validation and proper resource management in kernel subsystems where race conditions can lead to system instability or security compromise. The resolution reinforces fundamental principles of concurrent programming in kernel space, emphasizing that all operations affecting shared resources must be protected by appropriate synchronization primitives throughout their complete execution lifecycle.