Fsck_ffs did not properly range-check the inode 'di_size'

field, so it was possible for a filesystem marked clean by fsck_ffs
to cause kernel crashes later when mounted. This could occur when
fsck_ffs was used to repair a badly corrupted filesystem.

As pointed out by bde, it is not sufficient to restrict di_size to
just the superblock fs_maxfilesize limit. The use of 32-bit logical
block numbers (both in fsck and the kernel) induces another file
size limit which is usually lower than fs_maxfilesize. Also, the
old 4.3BSD filesystem does not have fs_maxfilesize initialised.

Following this change, fsck_ffs will enforce exactly the same
file size limits as are used by the kernel.

PR:		kern/15065
Discussed with:	bde
Reviewed by:	bde, mckusick

0 files changed, 0 insertions, 0 deletions