CVE-2026-23168 Overview
CVE-2026-23168 is a race condition vulnerability in the Linux kernel's flexible proportions (flex_proportions) subsystem. The vulnerability exists in the fprop_new_period() function, which is not hardirq safe, leading to a potential deadlock scenario. This issue was reported through lockdep analysis, which detected a locking contention between softirq and hardirq contexts during writeback operations.
The race condition occurs when a timer fires and fprop_new_period() acquires a write lock on the sequence counter while in softirq context. If a hardirq is raised during this critical section, the interrupt handler may attempt to read from the same sequence counter, causing an indefinite loop due to encountering an odd sequence number.
Critical Impact
Systems utilizing FUSE filesystems or block devices with configured maximum writeback throughput fractions are particularly susceptible to this deadlock condition, potentially causing system hangs or unresponsive I/O operations.
Affected Products
- Linux Kernel (multiple versions)
- Systems using FUSE filesystems with configured maximum writeback fractions
- Block device configurations utilizing flex_proportions for I/O scheduling
Discovery Timeline
- 2026-02-14 - CVE-2026-23168 published to NVD
- 2026-02-18 - Last updated in NVD database
Technical Details for CVE-2026-23168
Vulnerability Analysis
The vulnerability resides in the Linux kernel's flexible proportions code, specifically within the fprop_new_period() function. This function uses a sequence counter (seqcount) to coordinate access to period-related data structures. The core issue is that the write section of this sequence counter is not interrupt-safe (irqsafe), creating a window for deadlock when hardirqs can preempt softirq processing.
The problematic code path begins when run_timer_softirq invokes writeout_period(), which calls fprop_new_period(). This function acquires a write lock via write_seqcount_begin(&p->sequence). While holding this lock, if a hardirq is raised, the interrupt handler's code path through blk_mq_end_request() → blk_update_request() → ext4_end_bio() → folio_end_writeback() → __wb_writeout_add() → __fprop_add_percpu_max() may call fprop_fraction_percpu(), which attempts to read the sequence counter.
When read_seqcount_begin() encounters an odd sequence number (indicating an ongoing write), it loops indefinitely waiting for the write to complete—a write that cannot complete because the current hardirq context has preempted the softirq that holds the lock.
Root Cause
The root cause is the lack of interrupt protection around the sequence counter write section in fprop_new_period(). The seqcount implementation expects readers to retry when they detect an odd sequence number, but this assumption breaks down when a hardirq interrupts the writer and then attempts to read from the same counter, creating an unresolvable circular dependency.
This scenario is particularly common on systems configured with FUSE block device interfaces (bdis) that set a maximum fraction of writeout throughput, as this triggers the conditional path in __fprop_add_percpu_max() that requires reading the sequence counter.
Attack Vector
This vulnerability is a local denial of service (DoS) condition that can be triggered under specific workload patterns. The attack vector requires:
- A system with FUSE filesystems or block devices configured with maximum writeback throughput fractions
- High I/O workload that generates concurrent timer events and block device completions
- Precise timing where a hardirq fires during the critical section of fprop_new_period()
The vulnerability manifests through the kernel's timer and block I/O subsystems. When a timer callback executes writeout_period() in softirq context and a block I/O completion hardirq fires during the sequence counter's critical section, the system experiences a deadlock. The hardirq handler's call to fprop_fraction_percpu() enters an infinite loop waiting for the sequence counter to become even, while the softirq context cannot progress because it's preempted by the hardirq.
This race condition does not require direct attacker interaction beyond creating I/O pressure conditions that increase the probability of the timing collision.
Detection Methods for CVE-2026-23168
Indicators of Compromise
- System lockups or hangs during heavy I/O workloads, particularly with FUSE filesystems
- Kernel lockdep warnings referencing flex_proportions, fprop_new_period, or sequence counter deadlocks
- Unresponsive processes blocked on I/O operations with no apparent progress
Detection Strategies
- Enable CONFIG_PROVE_LOCKING (lockdep) in kernel configuration to detect this race condition proactively
- Monitor system logs for lockdep splats or warnings related to flex_proportions or seqcount locking issues
- Deploy kernel tracing to identify contention in fprop_new_period() and related writeback functions
Monitoring Recommendations
- Configure system monitoring to alert on kernel soft lockups or hung task warnings
- Monitor FUSE filesystem performance metrics for unexpected latency spikes or stalls
- Implement watchdog timers to detect and recover from kernel deadlock conditions
How to Mitigate CVE-2026-23168
Immediate Actions Required
- Update the Linux kernel to a patched version that includes the fix for making fprop_new_period() hardirq safe
- Review system configurations for FUSE filesystems with custom maximum writeback fraction settings
- Consider temporarily avoiding high-concurrency I/O workloads on affected systems until patched
Patch Information
The fix ensures that the write section of the sequence counter in fprop_new_period() is interrupt-safe by properly disabling interrupts during the critical section. Multiple kernel stable branches have received patches addressing this vulnerability:
- Linux Kernel Commit 0acc9ba7
- Linux Kernel Commit 78ede9eb
- Linux Kernel Commit 884b2590
- Linux Kernel Commit b91a8429
- Linux Kernel Commit dd9e2f5b
Workarounds
- Reduce I/O concurrency on systems with FUSE filesystems until patches can be applied
- Avoid configuring maximum writeback throughput fractions on vulnerable kernels if possible
- Implement process isolation to limit the impact of potential deadlocks to non-critical workloads
# Check current kernel version
uname -r
# Verify if lockdep is enabled for detection
grep CONFIG_PROVE_LOCKING /boot/config-$(uname -r)
# Update kernel on Debian/Ubuntu systems
sudo apt update && sudo apt upgrade linux-image-generic
# Update kernel on RHEL/CentOS systems
sudo yum update kernel
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
