linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Thiemo Nagel <thiemo.nagel@ph.tum.de>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: fix null pointer deref on mount
Date: Mon, 5 Jan 2009 18:44:11 -0500	[thread overview]
Message-ID: <20090105234411.GD14500@mit.edu> (raw)
In-Reply-To: <49628EBF.2040805@ph.tum.de>

> @@ -2145,9 +2145,11 @@
>  	if (EXT4_BLOCKS_PER_GROUP(sb) == 0)
>  		goto cantfind_ext4;
>  
> -	/* ensure blocks_count calculation below doesn't sign-extend */
> -	if (ext4_blocks_count(es) + EXT4_BLOCKS_PER_GROUP(sb) <
> -	    le32_to_cpu(es->s_first_data_block) + 1) {
> +	/*
> +	 * ensure blocks_count calculation below doesn't sign-extend
> +	 * and after do_div() still blocks_count > 0
> +	 */
> +	if (ext4_blocks_count(es) < le32_to_cpu(es->s_first_data_block) + 1) {
>  		printk(KERN_WARNING "EXT4-fs: bad geometry: block count %llu, "
>  		       "first data block %u, blocks per group %lu\n",
>  			ext4_blocks_count(es),

I'd rewrite the test as:

	/*
	 * It makes no sense for the first data block to be beyond the end
	 * of the filesystem.
	 */
	if (le32_to_cpu(es->s_first_data_block) >= ext4_blocks_count(es)) {
  		printk(KERN_WARNING "EXT4-fs: bad geometry: first data"
			"block %u is beyond end of filesystem(%llu)\n",
			le32_to_cpu(es->s_first_data_block),
			ext4_blocks_count(es));
		...

There's no point printing the blocks per group if it's no longer in
the test, and having the comment talk about the physical meaning of
the superblock rather some esoteric explanation about sign extension
and do_div() is much more understable.

> @@ -2160,6 +2162,15 @@
>  			EXT4_BLOCKS_PER_GROUP(sb) - 1);
>  	do_div(blocks_count, EXT4_BLOCKS_PER_GROUP(sb));
>  	sbi->s_groups_count = blocks_count;
> +	if (sbi->s_groups_count > ((uint64_t)1<<32) - EXT4_DESC_PER_BLOCK(sb)) {

This can't possibly work, given that s_groups_count is an unsigned
int.  Even if were unsigned long, it wouldn't have worked on an x86_32
machine, since unsigned long is 32 bits on an x86_32.  See why it's
BadBadBad to use unsigned long?  It means that people running on
x86_64 machines can get deluded into thinking that code will work,
when in fact it won't work everywhere.

The blocks_count variable *is* an __u64, so simply using blocks_count
in the test would fix this problem.

						- Ted

  parent reply	other threads:[~2009-01-05 23:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05  1:19 [PATCH] ext4: fix null pointer deref on mount Thiemo Nagel
2009-01-05 17:02 ` Theodore Tso
2009-01-05 20:50   ` Thiemo Nagel
2009-01-05 21:39     ` Theodore Tso
2009-01-05 22:50       ` Thiemo Nagel
2009-01-05 23:34         ` Theodore Tso
2009-01-05 23:44         ` Theodore Tso [this message]
2009-01-06  4:12           ` Theodore Tso
2009-01-22  0:43             ` Thiemo Nagel
2009-01-06 12:46           ` Thiemo Nagel
2009-01-06 13:25             ` Theodore Tso
2009-01-06 16:32               ` Thiemo Nagel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090105234411.GD14500@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=thiemo.nagel@ph.tum.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).