linux-kernel - [PATCH] hfs: correct return value in hfs_fill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1163715533.22367.10.camel@localhost.localdomain>
Date:	Thu, 16 Nov 2006 17:18:53 -0500
From:	Eric Paris <eparis@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	zippel@...ux-m68k.org
Subject: [PATCH] hfs: correct return value in hfs_fill_super()

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@...hat.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/