CVE-2024-36908 in Linux
Summary
by MITRE • 05/30/2024
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: do not WARN if iocg was already offlined
In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time:
WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0
The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns.
Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/30/2025
The vulnerability CVE-2024-36908 addresses a logical error in the Linux kernel's block I/O control subsystem, specifically within the blk-iocost module. This issue manifests as an inappropriate warning message during the removal of block control groups or disk devices, which can lead to confusion and potential misinterpretation of system health status. The problem occurs in the iocg_pay_debt() function where a warning is triggered when the active_list is empty, intended to verify that an iocg (I/O control group) is active when it has debt. However, this warning becomes invalid during the cleanup process of blkcg or disk removal operations.
The technical flaw arises from the timing of when the warning is triggered in relation to the cleanup sequence. When iocg_waitq_timer_fn() executes during the removal of a block control group or disk, it can access an iocg that has already been marked for removal but not yet fully cleaned up. The call trace shows the warning originates from iocg_pay_debt() function at line 1402, which is invoked through the chain of iocg_kick_waitq() and iocg_waitq_timer_fn() functions. This sequence demonstrates a race condition where the warning logic does not account for the transitional state of iocg objects during removal operations.
The operational impact of this vulnerability primarily affects system administrators and monitoring tools that rely on kernel warning messages for system health assessment. The spurious warning messages can clutter system logs and potentially mask genuine issues, making it difficult to identify actual problems in the I/O subsystem. This issue is particularly concerning in production environments where log analysis is used for troubleshooting and performance monitoring. The warning does not indicate a functional problem with the system but rather reflects a design oversight in handling the cleanup process of I/O control groups.
The fix implemented addresses this by adding a check to determine if the iocg was already offlined before triggering the warning. This approach follows the principle of defensive programming and aligns with the established pattern of ensuring proper cleanup sequences in kernel modules. The solution ensures that when iocg objects are removed, the warning logic recognizes that the iocg is in a transitional state and avoids generating meaningless warnings. The fix is consistent with the kernel's approach to handling object cleanup where the waitq_timer is explicitly canceled after removing the active_list in ioc_pd_free() function, ensuring proper synchronization between cleanup operations and warning generation.
This vulnerability demonstrates the importance of considering all possible execution paths during kernel development, particularly in subsystems that handle resource cleanup and object lifecycle management. The issue relates to CWE-691, which covers insufficient control flow management, and can be associated with ATT&CK technique T1490, specifically the use of system resource hijacking through improper handling of resource cleanup operations. The fix ensures that kernel subsystems properly distinguish between legitimate operational conditions and cleanup artifacts, maintaining the integrity of system monitoring and diagnostic information.