Searched hist:71884 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-11-stable/sbin/fsck_ffs/ | ||
| H A D | pass1.c | diff 71884 Wed Jan 31 13:16:56 MST 2001 iedowse 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 |
| H A D | setup.c | diff 71884 Wed Jan 31 13:16:56 MST 2001 iedowse 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 |
Completed in 46 milliseconds