CVE-2025-68807 Overview
A race condition vulnerability has been identified in the Linux kernel's block layer subsystem, specifically in the wbt_enable_default() function. When this function is moved out of queue freezing in elevator_change(), it can cause the write-back throttling (WBT) inflight counter to become negative (-1), leading to hung tasks in the writeback path.
Critical Impact
This vulnerability can cause tasks to become stuck indefinitely in wbt_wait() due to an inconsistent counter state, resulting in system hangs and denial of service conditions affecting kernel stability.
Affected Products
- Linux kernel with block layer WBT (Write-Back Throttling) enabled
- Systems using elevator/IO scheduler changes at runtime
- Kernel configurations with CONFIG_BLK_WBT enabled
Discovery Timeline
- 2026-01-13 - CVE CVE-2025-68807 published to NVD
- 2026-01-13 - Last updated in NVD database
Technical Details for CVE-2025-68807
Vulnerability Analysis
This race condition occurs in the Linux kernel's block I/O quality of service (QoS) subsystem, specifically within the Write-Back Throttling (WBT) mechanism. The vulnerability manifests when wbt_enable_default() executes concurrently with I/O submission operations.
The core issue stems from a timing window where the WBT state can be updated between the call to wbt_wait() (via rq_qos_throttle()) and the subsequent call to wbt_track() (via rq_qos_track()). When rwb_enabled() checks the state during this window, the inflight counter can be decremented before proper initialization occurs, causing it to underflow to -1.
This results in a deadlock condition where tasks waiting for the counter become permanently blocked, as evidenced by hung task warnings showing processes in state D (uninterruptible sleep) with call traces through rq_qos_wait(), wbt_wait(), and blk_mq_submit_bio().
Root Cause
The root cause is improper synchronization between the WBT initialization path and the I/O submission path. Specifically, when wbt_enable_default() was moved outside of queue freezing in elevator_change(), it created a race window where:
- The WBT state could be partially initialized
- Concurrent I/O submissions could decrement the inflight counter
- The counter becomes negative due to the initialization race
- Tasks waiting on the counter never get woken up due to the inconsistent state
The diagnostic signature shows rq_wait[0].inflight: -1 with has_waiters: True, indicating the deadlock condition.
Attack Vector
This vulnerability is triggered locally through legitimate system operations that cause elevator/IO scheduler changes while I/O is in flight. The race condition can be triggered by:
- Changing I/O schedulers via sysfs while the system is under I/O load
- Enabling or disabling BFQ or iocost I/O schedulers at runtime
- Any operation that triggers wbt_enable_default() during active I/O submission
While not directly exploitable for code execution, an attacker with local access could potentially trigger this race condition intentionally to cause a denial of service by inducing system hangs.
Detection Methods for CVE-2025-68807
Indicators of Compromise
- Processes stuck in D (uninterruptible sleep) state with stack traces through wbt_wait()
- Hung task warnings in kernel logs showing kworker processes blocked in rq_qos_wait()
- WBT inflight counter showing negative values (-1) in debug output
- System I/O operations becoming unresponsive after scheduler changes
Detection Strategies
- Monitor kernel logs for hung task warnings mentioning wbt_wait or rq_qos_wait in the call trace
- Check /sys/kernel/debug/block/*/rq_qos/ for WBT state anomalies if debugfs is available
- Implement monitoring for processes in D state with extended duration (exceeding hung_task_timeout_secs)
- Track I/O scheduler change events that may trigger the race condition
Monitoring Recommendations
- Enable kernel hung task detection with appropriate timeout thresholds
- Configure alerting for unusual numbers of processes in uninterruptible sleep state
- Monitor system I/O latency for sudden increases that may indicate hung writeback operations
- Log elevator/scheduler changes for correlation with any system hang events
How to Mitigate CVE-2025-68807
Immediate Actions Required
- Apply the kernel patches from the stable git repository to remediate the race condition
- Avoid changing I/O schedulers on production systems under heavy I/O load until patched
- Consider freezing I/O queues manually before scheduler changes as a temporary workaround
- Monitor systems for hung task warnings indicating this issue
Patch Information
The vulnerability has been addressed through kernel patches that restructure the WBT initialization logic:
- Commit 9869d3a6fed3 - Primary fix splitting wbt_enable_default() into separate functions
- Commit f55201fb3bec - Additional changes for proper WBT initialization
The fix introduces __wbt_enable_default(), wbt_enable_default(), and wbt_init_enable_default() functions to ensure proper initialization ordering and removes the now-unnecessary ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT flag.
Workarounds
- Avoid runtime I/O scheduler changes on production systems until patches are applied
- If scheduler changes are necessary, perform them during low I/O activity periods
- Consider rebooting affected systems if hung tasks are detected rather than waiting indefinitely
- Freeze I/O queues before making scheduler changes using appropriate block layer interfaces
# Check current WBT status and scheduler before making changes
cat /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/wbt_lat_usec
# Reduce I/O load before scheduler changes
sync
echo 3 > /proc/sys/vm/drop_caches
# If applying patches, verify commit hashes after kernel update
uname -r
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

