CVE-2026-72105 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-log: fix a bitset_size overflow on 32bit machines
Commit c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid.
Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides in the device mapper logging subsystem of the Linux kernel where a critical overflow condition can occur on 32-bit architectures. This issue affects the dm-log module which manages bitmap-based logging for device mapper operations. The problem stems from an improper handling of bitset_size calculations when converting region_count values into memory allocation requirements for bitmap storage structures.
The technical flaw manifests in the calculation logic where bitset_size is derived from region_count through a rounding operation to the nearest multiple of BITS_PER_LONG. When region_count approaches UINT_MAX values, the rounding process causes bitset_size to overflow and wrap around to zero on 32-bit systems despite the original region_count being valid. This represents a classic integer overflow vulnerability that can lead to memory allocation failures or potentially exploitable conditions.
The operational impact of this vulnerability is significant for systems running 32-bit kernels where device mapper operations involving large numbers of regions could trigger the overflow condition. The failure occurs during bitmap memory allocation when the calculated bitset_size becomes zero due to wraparound, causing allocation failures that can disrupt storage operations and potentially lead to system instability or denial of service conditions.
This vulnerability aligns with CWE-190 which addresses integer overflow and underflow conditions, specifically targeting the improper handling of large integer values during arithmetic operations. The issue also relates to ATT&CK technique T1499.001 which covers network denial of service attacks through resource exhaustion, as the overflow can lead to memory allocation failures that impact system resources.
The fix implemented in commit c20e36b7631d addresses this by introducing a special case handling for the rollover condition where bitset_size becomes zero. When this occurs, the system correctly calculates the bitset_size as the number of bytes required to hold 2^32 bits rather than allowing the wraparound to produce a zero value. This ensures proper memory allocation regardless of the region_count magnitude while maintaining compatibility with existing functionality.
The mitigation strategy focuses on ensuring proper integer overflow detection and handling in the bitmap size calculation logic. The solution requires careful consideration of the mathematical relationship between region_count, BITS_PER_LONG, and the resulting bitset_size to prevent wraparound conditions. This approach demonstrates the importance of robust integer arithmetic handling in kernel space operations where such vulnerabilities can have system-wide implications.
The fix maintains backward compatibility while addressing the specific architectural limitation of 32-bit systems where size_t variables can overflow during calculations involving large values. The implementation ensures that even when region_count approaches maximum valid values, the bitmap allocation process will proceed correctly without triggering memory allocation failures or undefined behavior scenarios.