CVE-2026-72369: minix: avoid overflow in bitmap block count calculation

In the Linux kernel, the following vulnerability has been resolved:

minix: avoid overflow in bitmap block count calculation

minixchecksuperblock() uses minixblocksneeded() 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 DIVROUNDUP() in unsigned int arithmetic. A Minix v3 image can set sninodes or szones near UINTMAX so the addition inside DIVROUNDUP() wraps to zero. That makes a zero imap/zmap block count look valid, after which minixfillsuper() can dereference simap[0] or szmap[0] even though no bitmap buffers were allocated.

Impact: mounting a crafted Minix v3 image whose sninodes or szones is near UINTMAX makes minixchecksuperblock() accept a zero bitmap-block count and minixfillsuper() dereference simap[0]/szmap[0], panicking the kernel.

The divisor is the bitmap capacity in bits, blocksize 8, which is always a power of two: minixfillsuper() obtains the block size through sbsetblocksize(), and blkvalidateblocksize() rejects any size that is not a power of two. Use DIVROUNDUPPOW2(), which divides before adding the round-up term and so cannot overflow for a power-of-two divisor.