Divide by Zero in Linux 2.4.31 and 2.6.14

Divide by Zero in Linux 2.4.31 and 2.6.14

[Can Sar]

Hi,

My research group is working on a tool that automatically finds bugs  
in FS mounting code by mount a "symbolic" disk. Our approach  
carefully (automatically) looks at the checks the FS does on the disk  
and sees if certain checks that prevent potential errors are missing.

There is a bug in both ext2 and 3 that was fixed in 2.6.10 where if  
s_blocks_per_group (in the ext2_superblock) is 0 this will cause a  
division by zero. Unfortunately, this bug is still in 2.4.31.

Furthermore, there is another bug where if s_inodes_per_group is 0 we  
again get a division by 0. This bug exists in both 2.6.14 and 2.4.31.

Finally, it seems that in the current implementation the EXT2/3 error  
mode that is set in the superblock cannot be overriden by the mount  
option if it is set to panic. This would mean that mounting a disk  
image with s_errors = 3 (EXT2_ERRORS_PANIC) and some false values in  
the superblock that are checked after s_errors is read will again  
cause a kernel panic. This is definitely the case in 2.4, and seems  
to be the case in 2.6 kernels as well though I haven't gotten around  
to trying that particular test case yet.

I hope these bug reports help. We are still in the early stages of  
using our tool and hope to provide you with more bug reports in the  
future.

Regards,
Can Sar

Re: Divide by Zero in Linux 2.4.31 and 2.6.14

[Andreas Dilger]

On Nov 03, 2005  05:03 -0800, Can Sar wrote:
> There is a bug in both ext2 and 3 that was fixed in 2.6.10 where if  
> s_blocks_per_group (in the ext2_superblock) is 0 this will cause a  
> division by zero. Unfortunately, this bug is still in 2.4.31.
> 
> Furthermore, there is another bug where if s_inodes_per_group is 0 we  
> again get a division by 0. This bug exists in both 2.6.14 and 2.4.31.

It is impossible to have an ext[23] filesystem with 0 blocks per group
or 0 inodes per group.  That said, it seems that ext[23]_fill_super()
check for too large values and not zero, so a patch to verify these
values at mount would be OK.

> Finally, it seems that in the current implementation the EXT2/3 error  
> mode that is set in the superblock cannot be overriden by the mount  
> option if it is set to panic. This would mean that mounting a disk  
> image with s_errors = 3 (EXT2_ERRORS_PANIC) and some false values in  
> the superblock that are checked after s_errors is read will again  
> cause a kernel panic. This is definitely the case in 2.4, and seems  
> to be the case in 2.6 kernels as well though I haven't gotten around  
> to trying that particular test case yet.

In ext3_fill_super() we do not call ext3_error() (only printk) so this
should not invoke panic() if there is an error during mount.  The
ERRORS_PANIC flag is cleared in parse_options() if some other errors=
behaviour is set, so I can't see the sequence of events that would
lead to the situation you describe.

> I hope these bug reports help. We are still in the early stages of  
> using our tool and hope to provide you with more bug reports in the  
> future.

Always good to have such checking done.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.