[PATCH] hfs: correct return value in hfs_fill_super()

[Eric Paris <eparis@redhat.com>]

When an invalid hfs filesystem image is mounted it may cause a number of
different oops.  One filesystem image which triggers this problem can be
found at:

http://projects.info-pull.com/mokb/MOKB-14-11-2006.html

it was created using the fsfuzzer program which can be found at:

http://people.redhat.com/sgrubb/files

Other such images which oops due to this same bug can be found using the
fsfuzzer.

Inside hfs_fill_super() the return value 'res' is set equal to
hfs_cat_find_brec().  If the return from  hfs_cat_find_brec() is failure
it will go to the error path and error out with an error return value.
If however hfs_cat_find_brec() returns success but then any of the
subsequent operations fail it will jump to the error path but the return
value will still be set to success from the hfs_cat_find_brec() call.
This patch simply sets a default return value of -EINVAL after the call
to hfs_cat_find_brec() so the error path will return an error instead of
success.

Although the link above shows the crash in SELinux code this is clearly
an hfs bug.  In this particular case hfs_iget() is unable to get the
root_inode and so it goes to bail_no_root: because of this bug we return
success and the s_root in the superblock struct is still 0 (since it was
initialized that way).  Later when SELinux actually tries to use the
super block s_root we panic since we are trying to deference a null
pointer.

Signed-off-by: Eric Paris <eparis@redhat.com>

 fs/hfs/super.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/hfs/super.c b/fs/hfs/super.c
index d43b4fc..ab5484e 100644
--- a/fs/hfs/super.c
+++ b/fs/hfs/super.c
@@ -390,6 +390,7 @@ static int hfs_fill_super(struct super_b
 		hfs_find_exit(&fd);
 		goto bail_no_root;
 	}
+	res = -EINVAL;
 	root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
 	hfs_find_exit(&fd);
 	if (!root_inode)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/