bin/44209: superblock check can fail erroneously in resize_ffs(8)

[riz%netbsd.org@localhost]

>Number:         44209
>Category:       bin
>Synopsis:       superblock check can fail erroneously in resize_ffs(8)
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 09 00:05:00 +0000 2010
>Originator:     Jeff Rizzo <riz%NetBSD.org@localhost>
>Release:        NetBSD 5.99.41
>Organization:
        
>Environment:
        
        
System: NetBSD netbsd6 5.99.41 NetBSD 5.99.41 (GENERIC) #0: Sun Dec 5 19:35:40 
PST 2010 riz@netbsd6:/home/riz/obj/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
        The superblock search code in resize_ffs(8) is looking
for the wrong things, and can falsely claim not to handle a particular
superblock.  Also, it's not ffsv2 format blocks it has trouble with,
but actually ffsv1.

This code in resize_ffs.c main() is the culprit:

        for (where = search[i = 0]; search[i] != -1; where = search[++i]) {
                readat(where / DEV_BSIZE, oldsb, SBLOCKSIZE);
                if (where == SBLOCK_UFS2 && (oldsb->fs_magic == FS_UFS1_MAGIC))
                        continue;
                if (oldsb->fs_magic == FS_UFS1_MAGIC)
                        break;
                if (oldsb->fs_old_flags & FS_FLAGS_UPDATED)
                        err(EXIT_FAILURE,
                            "Can't resize ffsv2 format superblock!");
        }

It is sometimes possible to hit the error condition on an otherwise-valid
file system.  The check should really be more like:

        if ((oldsb->fs_old_flags & FS_FLAGS_UPDATED) == 0)
                errx(EXIT_FAILURE, "Can't resize v1 format superblock!\n"
                    "Consider updating to a v2 superblock with "
                    "fsck_ffs -c 4.");

>How-To-Repeat:
        Try to resize a filesystem with just the wrong data.
>Fix:
        I have a fix in my local tree;  there are some more extensive changes
that will be made at the same time, so I'm holding off for a few days.


This PR is filed primarily because I will likely commit an expected-fail test
prior to fixing this PR.

>Unformatted: