minix: avoid overflow in bitmap block count calculation

Summary

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.

Timeline

1. Aug 15, 2026, 5:56 AM UTCCVE published
2. Aug 17, 2026, 5:43 AM UTCRecord last updated

Affected versions

• Linux Linux

  From 6.6.128 · fixed in 6.6.145; From 6.12.75 · fixed in 6.12.97; From 6.18.16 · fixed in 6.18.40; From 5.10.252 · fixed in 5.11; From 5.15.202 · fixed in 5.16; From 6.1.165 · fixed in 6.2; From 6.19.6 · fixed in 6.20

• Linux Linux

  7.0

References 5