CVE-2026-23168 in Linux
Summary
by MITRE • 02/14/2026
In the Linux kernel, the following vulnerability has been resolved:
flex_proportions: make fprop_new_period() hardirq safe
Bernd has reported a lockdep splat from flexible proportions code that is essentially complaining about the following race:
<timer fires> run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence);
<hardirq is raised> ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) {
fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - sees odd sequence so loops indefinitely
Note that a deadlock like this is only possible if the bdi has configured maximum fraction of writeout throughput which is very rare in general but frequent for example for FUSE bdis. To fix this problem we have to make sure write section of the sequence counter is irqsafe.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 05/05/2026
The vulnerability CVE-2026-23168 represents a critical race condition within the Linux kernel's flexible proportions subsystem that specifically affects the fprop_new_period() function's interaction with hardware interrupts. This issue manifests as a lockdep splat indicating an improper handling of sequence counters during concurrent execution contexts. The flaw occurs when a timer interrupt fires while the system is processing a softirq context, creating a scenario where hardware interrupts can interfere with the sequence counter operations that are meant to be atomic and safe from concurrent modifications. The vulnerability is particularly concerning because it can lead to indefinite loops and potential system instability when the sequence counter read operations encounter odd sequence values that cause the system to spin indefinitely.
The technical implementation of this vulnerability stems from the improper handling of sequence counters in the flexible proportions code path that manages writeout throughput for block device interfaces. When the writeout_period function calls fprop_new_period(), it begins a sequence counter write operation using write_seqcount_begin(&p->sequence) which is designed to protect against concurrent modifications. However, the race condition occurs when a hardirq is raised during this critical section, allowing the interrupt handler to execute while the sequence counter is in an inconsistent state. The specific failure point occurs in the fprop_fraction_percpu() function where read_seqcount_begin(&p->sequence) encounters an odd sequence number, causing the system to enter an infinite loop as the read operation continuously fails to obtain a consistent sequence value.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially causing system hangs or unresponsiveness, particularly in environments where FUSE block device interfaces are heavily utilized. The vulnerability's rarity in general system configurations makes it less likely to be encountered in typical deployments, but its presence in FUSE bdis and other specialized block device implementations means that systems relying on these components face significant risk. The issue demonstrates a fundamental flaw in interrupt handling within kernel sequence counter mechanisms, where the assumption that sequence counter operations are safe from hardware interrupts is violated. This creates a dangerous scenario where a well-timed hardware interrupt can cause the system to enter an infinite loop, effectively rendering the affected subsystem unusable until manual intervention occurs.
This vulnerability aligns with CWE-362, which addresses race conditions in concurrent execution contexts, and specifically relates to the improper handling of sequence counters in kernel-level concurrency control mechanisms. The ATT&CK framework would categorize this under privilege escalation through kernel vulnerabilities, as the race condition could potentially be exploited to cause system instability or denial of service attacks. The fix implemented addresses the core issue by making the write section of the sequence counter operation hardirq safe, ensuring that critical sequence counter modifications cannot be interrupted by hardware interrupts. This approach follows established kernel security practices for managing concurrent access to shared data structures and demonstrates the importance of considering all possible interrupt contexts when designing atomic operations. The mitigation strategy specifically targets the problematic interaction between timer softirq contexts and hardware interrupt handlers, ensuring that sequence counter operations maintain their atomicity regardless of the execution context.