Description of problem:
The execute function in misc/fsck.c allocates an fsck_instance struct to
represent the fsck program being executed. This structure is not freed before
returning via three of the error paths:

/*
 * Execute a particular fsck program, and link it into the list of
 * child processes we are waiting for.
 */
static int execute(const char *type, const char *device, const char *mntpt,
                   int interactive)
{
        char *s, *argv[80], prog[80];
        int  argc, i;
        struct fsck_instance *inst, *p;
        pid_t   pid;

        inst = malloc(sizeof(struct fsck_instance));
        if (!inst)
                return ENOMEM;
        memset(inst, 0, sizeof(struct fsck_instance));
...
        s = find_fsck(prog);
        if (s == NULL) {
                fprintf(stderr, _("fsck: %s: not found\n"), prog);
*               return ENOENT;
        }
...
        /* Fork and execute the correct program. */
        if (noexecute)
                pid = -1;
        else if ((pid = fork()) < 0) {
                perror("fork");
*               return errno;
        } else if (pid == 0) {
                if (!interactive)
                        close(0);
                (void) execv(s, argv);
                perror(argv[0]);
*               exit(EXIT_ERROR);
        }
...
}

In each case, the return/exit should be preceded by a "free(inst);". The final
case is a bit moot as we're about to terminate the process anyway.

Version-Release number of selected component (if applicable):
e2fsprogs-1.35-12.4.EL4

How reproducible:
100%

Steps to Reproduce:
The first condition is easiest to reproduce and can be seen with valgrind.

1. Move or remove an fsck helper command that fsck will attempt to exec (e.g.
/sbin/fsck.ext2)
2. Run fsck under valgrind:
# valgrind --tool=memcheck fsck /some/ext2/fs
  
Actual results:
The output's a bit noisy & there seem to be some other leaks reported in blkid
code, but there is a clear difference in leaks following the addition of this patch:

==19795== LEAK SUMMARY:
==19795==    definitely lost: 1,080 bytes in 4 blocks.
==19795==      possibly lost: 0 bytes in 0 blocks.
==19795==    still reachable: 1,000 bytes in 46 blocks.
==19795==         suppressed: 0 bytes in 0 blocks.
==19795== Use --leak-check=full to see details of leaked memory.


Expected results:
After applying the patch for these problems, the leak count goes down by exactly
one block (36 bytes):

==21531== LEAK SUMMARY:
==21531==    definitely lost: 1,044 bytes in 3 blocks.
==21531==      possibly lost: 0 bytes in 0 blocks.
==21531==    still reachable: 1,000 bytes in 46 blocks.
==21531==         suppressed: 0 bytes in 0 blocks.
==21531== Use --leak-check=full to see details of leaked memory.