All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Copeland <me@bobcopeland.com>
To: Fabian Frederick <fabf@skynet.be>
Cc: linux-kernel@vger.kernel.org,
	linux-karma-devel@lists.sourceforge.net,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH V2 resend] FS/OMFS: block number sanity check during fill_super operation
Date: Mon, 29 Sep 2014 15:38:23 -0400	[thread overview]
Message-ID: <20140929193823.GJ6835@localhost> (raw)
In-Reply-To: <1412010428-10642-1-git-send-email-fabf@skynet.be>

On Mon, Sep 29, 2014 at 07:07:08PM +0200, Fabian Frederick wrote:
> This patch defines maximum block number to 2^31.
> It also converts bitmap_size and array_size to
> unsigned int in omfs_get_imap
> 
> Suggested-By: Linus Torvalds <torvalds@linux-foundation.org>
> Suggested-By: Bob Copeland <me@bobcopeland.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Bob Copeland <me@bobcopeland.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> This is untested.

Acked-by: Bob Copeland <me@bobcopeland.com>

I also gave it a quick test.  For just plain corruption of s_num_blocks,
there's a later check that one would normally hit since the number is
stored in a second place, and we compare them.  But if both
omfs_rb->r_num_blocks and sbi->s_num_blocks are the same insane number, I
agree we should give up here.

-- 
Bob Copeland %% www.bobcopeland.com

      reply	other threads:[~2014-09-29 19:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-29 17:07 [PATCH V2 resend] FS/OMFS: block number sanity check during fill_super operation Fabian Frederick
2014-09-29 19:38 ` Bob Copeland [this message]

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=20140929193823.GJ6835@localhost \
    --to=me@bobcopeland.com \
    --cc=akpm@linux-foundation.org \
    --cc=fabf@skynet.be \
    --cc=linux-karma-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.