CVE-2025-40061 in Linux
Summary
by MITRE • 10/28/2025
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix race in do_task() when draining
When do_task() exhausts its iteration budget (!ret), it sets the state to TASK_STATE_IDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASK_STATE_DRAINING state set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().
While state changes are protected by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish draining in the while(!is_done(task)) loop. The race occurs if do_task() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free.
This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost.
Fix this by restoring the original pre-migration behavior. If the state is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASK_STATE_DRAINED, stopping the task as intended.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/20/2026
The vulnerability described in CVE-2025-40061 affects the Linux kernel's RDMA/rxe subsystem, specifically within the do_task() function responsible for managing task execution in the remote execution (rxe) driver. This issue represents a race condition that can lead to critical system instability and potential security implications. The vulnerability occurs during the transition from tasklets to workqueues in the kernel's execution model, where the original handling of draining states was inadvertently removed during the migration process. The problem manifests when the do_task() function reaches its iteration budget limit and attempts to reschedule itself without properly accounting for concurrent state changes that may be occurring in other execution paths.
The technical flaw stems from inadequate synchronization logic within the task management system where the do_task() function checks if it has exhausted its iteration budget and sets the task state to TASK_STATE_IDLE for rescheduling. However, this operation occurs without verifying whether the task state has been concurrently modified by other functions such as rxe_cleanup_task() or rxe_disable_task(). These cleanup functions, while holding the spinlock initially, release it during their waiting period in the while(!is_done(task)) loop, creating a temporal window where do_task() can acquire the lock and overwrite the TASK_STATE_DRAINING state with TASK_STATE_IDLE. This race condition can result in a task rescheduling itself incorrectly while another thread believes the task is in the process of being cleaned up, leading to potential use-after-free conditions that could be exploited by malicious actors.
The operational impact of this vulnerability extends beyond simple system instability into potential security risks within the kernel's memory management and process execution model. When a task incorrectly reschedules itself during the draining phase, it can lead to memory corruption patterns that might be leveraged for privilege escalation or denial-of-service attacks. The vulnerability affects systems utilizing RDMA (Remote Direct Memory Access) functionality through the rxe driver, which is commonly deployed in high-performance computing environments and data center networks where reliable task execution is critical. The race condition can cause unpredictable behavior in network packet processing and memory management operations, potentially leading to system crashes or corrupted memory states that could be exploited to gain unauthorized access to system resources. This type of vulnerability is particularly concerning in enterprise environments where RDMA acceleration is used for high-speed data processing and network communications.
The fix implemented for CVE-2025-40061 addresses the root cause by restoring the pre-migration behavior that properly handled the draining state transition. The solution involves modifying the do_task() function to check if the task state is TASK_STATE_DRAINING when iterations are exhausted, and if so, setting the continuation flag to 1 to force a new loop iteration. This approach ensures that tasks in the draining state can complete their work before transitioning to the final TASK_STATE_DRAINED state, maintaining proper synchronization between the task execution and cleanup processes. This fix aligns with the principles outlined in CWE-362, which addresses race conditions in concurrent programming, and follows ATT&CK technique T1068, which covers local privilege escalation through kernel vulnerabilities. The remediation restores the proper state machine behavior that was lost during the tasklet to workqueue migration, ensuring that all task lifecycle transitions occur correctly and maintain memory safety throughout the execution process.
This vulnerability demonstrates the complexity of kernel-level race condition management and the importance of maintaining proper synchronization mechanisms during system architecture migrations. The issue highlights how seemingly minor changes in code structure can introduce significant security implications, particularly in low-level kernel subsystems where timing and state management are critical. Organizations using Linux systems with RDMA capabilities should prioritize applying this patch to prevent potential exploitation of the race condition, as the vulnerability could enable attackers to manipulate kernel memory structures through carefully crafted network operations. The fix serves as a reminder of the importance of thorough testing during architectural transitions and the necessity of maintaining comprehensive state management protocols in concurrent execution environments. The vulnerability's classification under industry standards emphasizes the critical nature of such issues in maintaining system integrity and preventing unauthorized access to kernel resources through carefully orchestrated timing attacks.