All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: Randy Dunlap <rdunlap@infradead.org>, linux-kernel@vger.kernel.org
Cc: syzbot+36315852ece4132ec193@syzkaller.appspotmail.com,
	kernel test robot <lkp@intel.com>,
	Dave Kleikamp <shaggy@kernel.org>,
	jfs-discussion@lists.sourceforge.net
Subject: Re: [PATCH v2] JFS: more checks for invalid superblock
Date: Fri, 18 Dec 2020 14:31:50 -0600	[thread overview]
Message-ID: <285a8ede-c901-7d8c-bd3a-e9ce8962e714@oracle.com> (raw)
In-Reply-To: <20201218201716.26613-1-rdunlap@infradead.org>

Thanks! This looks good and reasonable. I'll try to get it pushed out to 
-next in the next few days.

Shaggy

On 12/18/20 2:17 PM, Randy Dunlap wrote:
> syzbot is feeding invalid superblock data to JFS for mount testing.
> JFS does not check several of the fields -- just assumes that they
> are good since the JFS_MAGIC and version fields are good.
> 
> In this case (syzbot reproducer), we have s_l2bsize == 0xda0c,
> pad == 0xf045, and s_state == 0x50, all of which are invalid IMO.
> Having s_l2bsize == 0xda0c causes this UBSAN warning:
>    UBSAN: shift-out-of-bounds in fs/jfs/jfs_mount.c:373:25
>    shift exponent -9716 is negative
> 
> s_l2bsize can be tested for correctness. pad can be tested for non-0
> and punted. s_state can be tested for its valid values and punted.
> 
> Do those 3 tests and if any of them fails, report the superblock as
> invalid/corrupt and let fsck handle it.
> 
> With this patch, chkSuper() says this when JFS_DEBUG is enabled:
>    jfs_mount: Mount Failure: superblock is corrupt!
>    Mount JFS Failure: -22
>    jfs_mount failed w/return code = -22
> 
> The obvious problem with this method is that next week there could
> be another syzbot test that uses different fields for invalid values,
> this making this like a game of whack-a-mole.
> 
> syzkaller link: https://syzkaller.appspot.com/bug?extid=36315852ece4132ec193
> 
> Reported-by: syzbot+36315852ece4132ec193@syzkaller.appspotmail.com
> Reported-by: kernel test robot <lkp@intel.com> # v2
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Dave Kleikamp <shaggy@kernel.org>
> Cc: jfs-discussion@lists.sourceforge.net
> ---
> v2: fix sparse __le32 warning (lkp robot)
> 
>   fs/jfs/jfs_filsys.h |    1 +
>   fs/jfs/jfs_mount.c  |   10 ++++++++++
>   2 files changed, 11 insertions(+)
> 
> --- lnx-510.orig/fs/jfs/jfs_mount.c
> +++ lnx-510/fs/jfs/jfs_mount.c
> @@ -37,6 +37,7 @@
>   #include <linux/fs.h>
>   #include <linux/buffer_head.h>
>   #include <linux/blkdev.h>
> +#include <linux/log2.h>
>   
>   #include "jfs_incore.h"
>   #include "jfs_filsys.h"
> @@ -366,6 +367,15 @@ static int chkSuper(struct super_block *
>   	sbi->bsize = bsize;
>   	sbi->l2bsize = le16_to_cpu(j_sb->s_l2bsize);
>   
> +	/* check some fields for possible corruption */
> +	if (sbi->l2bsize != ilog2((u32)bsize) ||
> +	    j_sb->pad != 0 ||
> +	    le32_to_cpu(j_sb->s_state) > FM_STATE_MAX) {
> +		rc = -EINVAL;
> +		jfs_err("jfs_mount: Mount Failure: superblock is corrupt!");
> +		goto out;
> +	}
> +
>   	/*
>   	 * For now, ignore s_pbsize, l2bfactor.  All I/O going through buffer
>   	 * cache.
> --- lnx-510.orig/fs/jfs/jfs_filsys.h
> +++ lnx-510/fs/jfs/jfs_filsys.h
> @@ -268,5 +268,6 @@
>   				 * fsck() must be run to repair
>   				 */
>   #define	FM_EXTENDFS 0x00000008	/* file system extendfs() in progress */
> +#define	FM_STATE_MAX 0x0000000f	/* max value of s_state */
>   
>   #endif				/* _H_JFS_FILSYS */
> 

      reply	other threads:[~2020-12-18 20:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-18 20:17 [PATCH v2] JFS: more checks for invalid superblock Randy Dunlap
2020-12-18 20:31 ` Dave Kleikamp [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=285a8ede-c901-7d8c-bd3a-e9ce8962e714@oracle.com \
    --to=dave.kleikamp@oracle.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=shaggy@kernel.org \
    --cc=syzbot+36315852ece4132ec193@syzkaller.appspotmail.com \
    /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.