CVE-2025-38083 in Linux
Summary
by MITRE • 06/20/2025
In the Linux kernel, the following vulnerability has been resolved:
net_sched: prio: fix a race in prio_tune()
Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 [1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
| | [5]: lock root
| [6]: rehash
| [7]: qdisc_tree_reduce_backlog()
| [4]: qdisc_put()
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 12/17/2025
The vulnerability identified as CVE-2025-38083 represents a critical race condition within the Linux kernel's traffic control subsystem, specifically affecting the PRIO queuing discipline implementation. This flaw exists in the net_sched component where the prio_tune() function fails to properly synchronize access to shared queuing structures during concurrent operations. The issue manifests when the Stochastic Fairness Queueing (SFQ) perturb timer fires at an inopportune moment, creating a temporal window where multiple CPU cores can simultaneously manipulate the same queuing data structures without proper mutual exclusion. The race condition occurs between the qdisc_tree_flush_backlog() operation and qdisc_tree_reduce_backlog() calls, where one CPU core releases a lock while another attempts to modify the queuing state, leading to inconsistent internal data structures.
The technical implementation of this vulnerability stems from improper locking mechanisms within the kernel's traffic control framework. When CPU 0 executes the sequence of locking the root qdisc, flushing backlog, and unlocking, it creates a window where CPU 1 can acquire the lock and perform rehash operations followed by backlog reduction. This timing dependency allows for the scenario where a parent qdisc's qlen (queue length) can become negative due to improper accounting during the race window. The vulnerability specifically impacts the PRIO queuing discipline which is used for prioritized traffic handling in network scheduling, making it particularly dangerous in network-intensive environments where multiple threads or cores process packet scheduling concurrently.
The operational impact of this vulnerability extends beyond simple data corruption, potentially leading to system instability and denial of service conditions in network processing environments. An attacker could exploit this race condition to cause underflow conditions in queue length calculations, which may result in kernel memory corruption or unpredictable behavior in the networking stack. This type of vulnerability is particularly concerning in high-performance networking scenarios where multiple CPU cores are actively processing network traffic and where the timing of SFQ perturb timer events can be manipulated or predicted. The flaw can be leveraged to create conditions that might lead to kernel panics or other critical system failures, especially in environments with heavy network load where the race condition is more likely to occur.
The mitigation strategy for this vulnerability involves modifying the implementation to use qdisc_purge_queue() instead of qdisc_tree_flush_backlog() within the prio_tune() function. This change ensures that all packets are purged from the queuing discipline before releasing any locks, thereby preventing the race condition from occurring. This approach aligns with established best practices for concurrent programming in kernel space where operations that require exclusive access to shared data structures must complete entirely before any locks are released. The fix addresses the root cause by ensuring that queue manipulation operations are atomic with respect to the locking mechanism, preventing the temporal window that allowed the race condition to occur. This remediation technique follows the principle of minimizing lock hold times and ensuring that all operations within a critical section complete before any potential lock release points, which is consistent with the recommendations found in the Linux kernel coding standards and security best practices. The solution directly addresses the underlying CWE-362 weakness related to race conditions in concurrent programming environments and provides a robust fix that maintains the intended functionality while eliminating the security risk.