CVE-2026-72369 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
minix: avoid overflow in bitmap block count calculation
minix_check_superblock() uses minix_blocks_needed() to verify that the on-disk imap and zmap block counts are large enough for the advertised inode and zone counts.
The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic. A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap block count look valid, after which minix_fill_super() can dereference s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated.
Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking
the kernel.
The divisor is the bitmap capacity in bits, blocksize * 8, which is always a power of two: minix_fill_super() obtains the block size through sb_set_blocksize(), and blk_validate_block_size() rejects any size that is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before adding the round-up term and so cannot overflow for a power-of-two divisor.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question affects the Linux kernel's handling of Minix filesystem images, specifically within the minix_check_superblock() function that validates superblock parameters. This issue arises from an arithmetic overflow condition during bitmap block count calculations that can lead to kernel panic and system instability. The flaw exists in how the kernel processes Minix v3 filesystem metadata where the s_ninodes and s_zones fields can be set to values approaching UINT_MAX, creating a scenario where unsigned integer arithmetic operations produce incorrect results.
The technical implementation of this vulnerability stems from the use of DIV_ROUND_UP() macro in unsigned integer arithmetic context. When processing filesystem superblocks, the minix_blocks_needed() helper function performs calculations that involve dividing by the bitmap capacity in bits, which is calculated as blocksize multiplied by 8. Since the kernel's blk_validate_block_size() function ensures block sizes are always powers of two, this divisor remains a power-of-two value throughout execution. However, the standard DIV_ROUND_UP() macro does not account for the specific properties of power-of-two divisors and can overflow when dealing with extreme values near UINT_MAX.
The operational impact of this vulnerability manifests when a maliciously crafted Minix v3 image is mounted on a Linux system. The attacker can set s_ninodes or s_zones fields to values close to UINT_MAX, causing the addition operation within DIV_ROUND_UP() to wrap around to zero due to unsigned integer overflow behavior. This zero result appears as a valid bitmap block count to minix_check_superblock(), which then proceeds to call minix_fill_super() without proper validation of allocated resources. The subsequent dereference of s_imap[0] or s_zmap[0] pointers occurs despite no actual bitmap buffers being allocated, leading to kernel panic and system crash.
This vulnerability aligns with CWE-191, Integer Underflow (Wrap or Wraparound), and CWE-192, Integer Overflow (Wrap or Wraparound) as it demonstrates how improper handling of arithmetic operations on unsigned integers can lead to security-relevant behavior. The issue also relates to ATT&CK technique T1547.001, Registry Run Keys / Startup Folder, since malicious filesystem images could be used in attack scenarios involving system boot processes or mount operations. The flaw represents a classic case of insufficient input validation and arithmetic overflow handling that can be exploited for privilege escalation or denial-of-service attacks against systems running affected kernel versions.
The mitigation strategy involves replacing the standard DIV_ROUND_UP() macro with DIV_ROUND_UP_POW2(), which is specifically designed to handle power-of-two divisors correctly by performing division before adding the rounding term. This approach prevents overflow conditions while maintaining the mathematical correctness of the bitmap block count calculation. The fix ensures that even when dealing with extreme values near UINT_MAX, the arithmetic operations produce predictable and safe results, eliminating the possibility of zero bitmap counts being accepted as valid while preventing the subsequent null pointer dereference that leads to kernel panic. This solution maintains backward compatibility while addressing the core arithmetic overflow issue in the filesystem validation logic.