From: Gao Xiang <hsiangkao@aol.com> To: Richard Weinberger <richard@nod.at> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Al Viro <viro@zeniv.linux.org.uk>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, devel <devel@driverdev.osuosl.org>, linux-erofs <linux-erofs@lists.ozlabs.org>, linux-kernel <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Stephen Rothwell <sfr@canb.auug.org.au>, tytso <tytso@mit.edu>, Pavel Machek <pavel@denx.de>, David Sterba <dsterba@suse.cz>, Amir Goldstein <amir73il@gmail.com>, Christoph Hellwig <hch@infradead.org>, Darrick <darrick.wong@oracle.com>, Dave Chinner <david@fromorbit.com>, Jaegeuk Kim <jaegeuk@kernel.org>, Jan Kara <jack@suse.cz>, torvalds <torvalds@linux-foundation.org>, Chao Yu <yuchao0@huawei.com>, Miao Xie <miaoxie@huawei.com>, Li Guifu <bluce.liguifu@huawei.com>, Fang Wei <fangwei1@huawei.com>, Gao Xiang <gaoxiang25@huawei.com> Subject: Re: [PATCH] erofs: move erofs out of staging Date: Sun, 18 Aug 2019 08:52:11 +0800 [thread overview] Message-ID: <20190818005202.GA3088@hsiangkao-HP-ZHAN-66-Pro-G1> (raw) In-Reply-To: <20190818000408.GA20778@hsiangkao-HP-ZHAN-66-Pro-G1> On Sun, Aug 18, 2019 at 08:04:11AM +0800, Gao Xiang wrote: > On Sun, Aug 18, 2019 at 07:38:47AM +0800, Gao Xiang wrote: > > Hi Richard, > > > > On Sun, Aug 18, 2019 at 01:25:58AM +0200, Richard Weinberger wrote: > > [] > > > > > > > While digging a little into the code I noticed that you have very few > > > checks of the on-disk data. > > > For example ->u.i_blkaddr. I gave it a try and created a > > > malformed filesystem where u.i_blkaddr is 0xdeadbeef, it causes the kernel > > > to loop forever around erofs_read_raw_page(). > > > > I don't fuzz all the on-disk fields for EROFS, I will do later.. > > You can see many in-kernel filesystems are still hardening the related > > stuff. Anyway, I will dig into this field you mentioned recently, but > > I think it can be fixed easily later. > > ...I take a simple try with the following erofs-utils diff and > a directory containing enwik9 only, with the latest kernel (5.3-rc) > and command line is > mkfs/mkfs.erofs -d9 enwik9.img testdir. > > diff --git a/lib/inode.c b/lib/inode.c > index 581f263..2540338 100644 > --- a/lib/inode.c > +++ b/lib/inode.c > @@ -388,8 +388,7 @@ static bool erofs_bh_flush_write_inode(struct erofs_buffer_head *bh) > v1.i_u.compressed_blocks = > cpu_to_le32(inode->u.i_blocks); > else > - v1.i_u.raw_blkaddr = > - cpu_to_le32(inode->u.i_blkaddr); > + v1.i_u.raw_blkaddr = 0xdeadbeef; > break; > } > > I tested the corrupted image with looped device and real blockdevice > by dd, and it seems fine.... > [36283.012381] erofs: initializing erofs 1.0 > [36283.012510] erofs: successfully to initialize erofs > [36283.012975] erofs: read_super, device -> /dev/loop17 > [36283.012976] erofs: options -> (null) > [36283.012983] erofs: root inode @ nid 36 > [36283.012995] erofs: mounted on /dev/loop17 with opts: (null). > [36297.354090] attempt to access beyond end of device > [36297.354098] loop17: rw=0, want=29887428984, limit=1953128 > [36297.354107] attempt to access beyond end of device > [36297.354109] loop17: rw=0, want=29887428480, limit=1953128 > [36301.827234] attempt to access beyond end of device > [36301.827243] loop17: rw=0, want=29887428480, limit=1953128 > [36371.426889] erofs: unmounted for /dev/loop17 > [36518.156114] erofs: read_super, device -> /dev/nvme0n1p4 > [36518.156115] erofs: options -> (null) > [36518.156260] erofs: root inode @ nid 36 > [36518.156384] erofs: mounted on /dev/nvme0n1p4 with opts: (null). > [36522.818884] attempt to access beyond end of device > [36522.818889] nvme0n1p4: rw=0, want=29887428984, limit=62781440 > [36522.818895] attempt to access beyond end of device > [36522.818896] nvme0n1p4: rw=0, want=29887428480, limit=62781440 > [36524.072018] attempt to access beyond end of device > [36524.072028] nvme0n1p4: rw=0, want=29887428480, limit=62781440 > > Could you give me more hints how to reproduce that? and I will > dig into more maybe it needs more conditions... I think I found what happened here... That is not a bug due to lack of check of on-disk ->u.i_blkaddr (seems block layer will handle access beyond end of device) but actually a bug of erofs_readdir: diff --git a/fs/erofs/data.c b/fs/erofs/data.c index fda16ec8863e..5b5f35d47370 100644 --- a/fs/erofs/data.c +++ b/fs/erofs/data.c @@ -329,6 +329,8 @@ static int erofs_raw_access_readpage(struct file *file, struct page *page) trace_erofs_readpage(page, true); + WARN_ON(1); + bio = erofs_read_raw_page(NULL, page->mapping, page, &last_block, 1, false); @@ -379,6 +381,8 @@ static int erofs_raw_access_readpages(struct file *filp, /* the rare case (end in gaps) */ if (unlikely(bio)) __submit_bio(bio, REQ_OP_READ, 0); + + WARN_ON(1); return 0; } diff --git a/fs/erofs/dir.c b/fs/erofs/dir.c index 637d70108d59..ccca954438ed 100644 --- a/fs/erofs/dir.c +++ b/fs/erofs/dir.c @@ -80,8 +80,10 @@ static int erofs_readdir(struct file *f, struct dir_context *ctx) unsigned int nameoff, maxsize; dentry_page = read_mapping_page(mapping, i, NULL); - if (IS_ERR(dentry_page)) - continue; + if (IS_ERR(dentry_page)) { + err = PTR_ERR(dentry_page); + break; + } de = (struct erofs_dirent *)kmap(dentry_page); It's a forever loop due to error handling of the read_mapping_page above. I will fix that in another patch and thanks for your report! Thanks, Gao Xiang > > Thanks, > Gao Xiang > > > > > Thanks, > > Gao Xiang > > > > > > > > Thanks, > > > //richard
WARNING: multiple messages have this Message-ID (diff)
From: hsiangkao@aol.com (Gao Xiang) Subject: [PATCH] erofs: move erofs out of staging Date: Sun, 18 Aug 2019 08:52:11 +0800 [thread overview] Message-ID: <20190818005202.GA3088@hsiangkao-HP-ZHAN-66-Pro-G1> (raw) In-Reply-To: <20190818000408.GA20778@hsiangkao-HP-ZHAN-66-Pro-G1> On Sun, Aug 18, 2019@08:04:11AM +0800, Gao Xiang wrote: > On Sun, Aug 18, 2019@07:38:47AM +0800, Gao Xiang wrote: > > Hi Richard, > > > > On Sun, Aug 18, 2019@01:25:58AM +0200, Richard Weinberger wrote: > > [] > > > > > > > While digging a little into the code I noticed that you have very few > > > checks of the on-disk data. > > > For example ->u.i_blkaddr. I gave it a try and created a > > > malformed filesystem where u.i_blkaddr is 0xdeadbeef, it causes the kernel > > > to loop forever around erofs_read_raw_page(). > > > > I don't fuzz all the on-disk fields for EROFS, I will do later.. > > You can see many in-kernel filesystems are still hardening the related > > stuff. Anyway, I will dig into this field you mentioned recently, but > > I think it can be fixed easily later. > > ...I take a simple try with the following erofs-utils diff and > a directory containing enwik9 only, with the latest kernel (5.3-rc) > and command line is > mkfs/mkfs.erofs -d9 enwik9.img testdir. > > diff --git a/lib/inode.c b/lib/inode.c > index 581f263..2540338 100644 > --- a/lib/inode.c > +++ b/lib/inode.c > @@ -388,8 +388,7 @@ static bool erofs_bh_flush_write_inode(struct erofs_buffer_head *bh) > v1.i_u.compressed_blocks = > cpu_to_le32(inode->u.i_blocks); > else > - v1.i_u.raw_blkaddr = > - cpu_to_le32(inode->u.i_blkaddr); > + v1.i_u.raw_blkaddr = 0xdeadbeef; > break; > } > > I tested the corrupted image with looped device and real blockdevice > by dd, and it seems fine.... > [36283.012381] erofs: initializing erofs 1.0 > [36283.012510] erofs: successfully to initialize erofs > [36283.012975] erofs: read_super, device -> /dev/loop17 > [36283.012976] erofs: options -> (null) > [36283.012983] erofs: root inode @ nid 36 > [36283.012995] erofs: mounted on /dev/loop17 with opts: (null). > [36297.354090] attempt to access beyond end of device > [36297.354098] loop17: rw=0, want=29887428984, limit=1953128 > [36297.354107] attempt to access beyond end of device > [36297.354109] loop17: rw=0, want=29887428480, limit=1953128 > [36301.827234] attempt to access beyond end of device > [36301.827243] loop17: rw=0, want=29887428480, limit=1953128 > [36371.426889] erofs: unmounted for /dev/loop17 > [36518.156114] erofs: read_super, device -> /dev/nvme0n1p4 > [36518.156115] erofs: options -> (null) > [36518.156260] erofs: root inode @ nid 36 > [36518.156384] erofs: mounted on /dev/nvme0n1p4 with opts: (null). > [36522.818884] attempt to access beyond end of device > [36522.818889] nvme0n1p4: rw=0, want=29887428984, limit=62781440 > [36522.818895] attempt to access beyond end of device > [36522.818896] nvme0n1p4: rw=0, want=29887428480, limit=62781440 > [36524.072018] attempt to access beyond end of device > [36524.072028] nvme0n1p4: rw=0, want=29887428480, limit=62781440 > > Could you give me more hints how to reproduce that? and I will > dig into more maybe it needs more conditions... I think I found what happened here... That is not a bug due to lack of check of on-disk ->u.i_blkaddr (seems block layer will handle access beyond end of device) but actually a bug of erofs_readdir: diff --git a/fs/erofs/data.c b/fs/erofs/data.c index fda16ec8863e..5b5f35d47370 100644 --- a/fs/erofs/data.c +++ b/fs/erofs/data.c @@ -329,6 +329,8 @@ static int erofs_raw_access_readpage(struct file *file, struct page *page) trace_erofs_readpage(page, true); + WARN_ON(1); + bio = erofs_read_raw_page(NULL, page->mapping, page, &last_block, 1, false); @@ -379,6 +381,8 @@ static int erofs_raw_access_readpages(struct file *filp, /* the rare case (end in gaps) */ if (unlikely(bio)) __submit_bio(bio, REQ_OP_READ, 0); + + WARN_ON(1); return 0; } diff --git a/fs/erofs/dir.c b/fs/erofs/dir.c index 637d70108d59..ccca954438ed 100644 --- a/fs/erofs/dir.c +++ b/fs/erofs/dir.c @@ -80,8 +80,10 @@ static int erofs_readdir(struct file *f, struct dir_context *ctx) unsigned int nameoff, maxsize; dentry_page = read_mapping_page(mapping, i, NULL); - if (IS_ERR(dentry_page)) - continue; + if (IS_ERR(dentry_page)) { + err = PTR_ERR(dentry_page); + break; + } de = (struct erofs_dirent *)kmap(dentry_page); It's a forever loop due to error handling of the read_mapping_page above. I will fix that in another patch and thanks for your report! Thanks, Gao Xiang > > Thanks, > Gao Xiang > > > > > Thanks, > > Gao Xiang > > > > > > > > Thanks, > > > //richard
next prev parent reply other threads:[~2019-08-18 0:54 UTC|newest] Thread overview: 170+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-17 8:23 [PATCH] erofs: move erofs out of staging Gao Xiang 2019-08-17 8:23 ` Gao Xiang 2019-08-17 21:19 ` Richard Weinberger 2019-08-17 21:19 ` Richard Weinberger 2019-08-17 22:07 ` Gao Xiang 2019-08-17 22:07 ` Gao Xiang 2019-08-17 23:25 ` Richard Weinberger 2019-08-17 23:25 ` Richard Weinberger 2019-08-17 23:38 ` Gao Xiang 2019-08-17 23:38 ` Gao Xiang 2019-08-18 0:04 ` Gao Xiang 2019-08-18 0:04 ` Gao Xiang 2019-08-18 0:52 ` Gao Xiang [this message] 2019-08-18 0:52 ` Gao Xiang 2019-08-18 8:16 ` Richard Weinberger 2019-08-18 8:16 ` Richard Weinberger 2019-08-18 8:45 ` Gao Xiang 2019-08-18 8:45 ` Gao Xiang 2019-08-18 9:03 ` Richard Weinberger 2019-08-18 9:03 ` Richard Weinberger 2019-08-18 9:09 ` Greg Kroah-Hartman 2019-08-18 9:09 ` Greg Kroah-Hartman 2019-08-18 9:21 ` Richard Weinberger 2019-08-18 9:21 ` Richard Weinberger 2019-08-18 10:12 ` Chao Yu 2019-08-18 10:12 ` Chao Yu 2019-08-18 15:11 ` Theodore Y. Ts'o 2019-08-18 15:11 ` Theodore Y. Ts'o 2019-08-18 15:58 ` Christoph Hellwig 2019-08-18 15:58 ` Christoph Hellwig 2019-08-18 16:16 ` Eric Biggers 2019-08-18 16:16 ` Eric Biggers 2019-08-18 16:22 ` Christoph Hellwig 2019-08-18 16:22 ` Christoph Hellwig 2019-08-18 16:33 ` Gao Xiang 2019-08-18 16:33 ` Gao Xiang 2019-08-18 17:29 ` Eric Biggers 2019-08-18 17:29 ` Eric Biggers 2019-08-18 17:47 ` Christoph Hellwig 2019-08-18 17:47 ` Christoph Hellwig 2019-08-18 18:16 ` Gao Xiang 2019-08-18 18:16 ` Gao Xiang 2019-08-18 20:14 ` Gao Xiang 2019-08-18 20:14 ` Gao Xiang 2019-08-19 7:35 ` Richard Weinberger 2019-08-19 7:35 ` Richard Weinberger 2019-08-19 8:02 ` Gao Xiang 2019-08-19 8:02 ` Gao Xiang 2019-08-19 10:34 ` [PATCH 0/6] staging: erofs: first stage of corrupted compressed images Gao Xiang 2019-08-19 10:34 ` Gao Xiang 2019-08-19 10:34 ` [PATCH 1/6] staging: erofs: some compressed cluster should be submitted for corrupted images Gao Xiang 2019-08-19 10:34 ` Gao Xiang 2019-08-19 14:36 ` Chao Yu 2019-08-19 14:36 ` Chao Yu 2019-08-19 14:36 ` Chao Yu 2019-08-19 14:39 ` Chao Yu 2019-08-19 14:39 ` Chao Yu 2019-08-19 14:39 ` Chao Yu 2019-08-19 10:34 ` [PATCH 2/6] staging: erofs: cannot set EROFS_V_Z_INITED_BIT if fill_inode_lazy fails Gao Xiang 2019-08-19 10:34 ` Gao Xiang 2019-08-19 14:43 ` Chao Yu 2019-08-19 14:43 ` Chao Yu 2019-08-19 14:43 ` Chao Yu 2019-08-19 10:34 ` [PATCH 3/6] staging: erofs: add two missing erofs_workgroup_put for corrupted images Gao Xiang 2019-08-19 10:34 ` Gao Xiang 2019-08-19 14:40 ` Chao Yu 2019-08-19 14:40 ` Chao Yu 2019-08-19 14:40 ` Chao Yu 2019-08-19 10:34 ` [PATCH 4/6] staging: erofs: avoid loop in submit chains Gao Xiang 2019-08-19 10:34 ` Gao Xiang 2019-08-19 14:50 ` Chao Yu 2019-08-19 14:50 ` Chao Yu 2019-08-19 14:50 ` Chao Yu 2019-08-19 10:34 ` [PATCH 5/6] staging: erofs: detect potential multiref due to corrupted images Gao Xiang 2019-08-19 10:34 ` Gao Xiang 2019-08-19 14:57 ` Chao Yu 2019-08-19 14:57 ` Chao Yu 2019-08-19 14:57 ` Chao Yu 2019-08-21 2:19 ` Greg Kroah-Hartman 2019-08-21 2:19 ` Greg Kroah-Hartman 2019-08-21 2:19 ` Greg Kroah-Hartman 2019-08-21 14:01 ` [PATCH v2 " Gao Xiang 2019-08-21 14:01 ` Gao Xiang 2019-08-21 14:24 ` Chao Yu 2019-08-21 14:24 ` Chao Yu 2019-08-19 10:34 ` [PATCH 6/6] staging: erofs: avoid endless loop of invalid lookback distance 0 Gao Xiang 2019-08-19 10:34 ` Gao Xiang 2019-08-19 14:58 ` Chao Yu 2019-08-19 14:58 ` Chao Yu 2019-08-19 14:58 ` Chao Yu 2019-08-19 16:09 ` [PATCH] erofs: move erofs out of staging Darrick J. Wong 2019-08-19 16:09 ` Darrick J. Wong 2019-08-19 16:09 ` Darrick J. Wong 2019-08-19 20:30 ` Gao Xiang 2019-08-19 20:30 ` Gao Xiang via Linux-erofs 2019-08-19 20:30 ` Gao Xiang 2019-08-20 0:55 ` Qu Wenruo 2019-08-20 0:55 ` Qu Wenruo 2019-08-20 0:55 ` Qu Wenruo 2019-08-20 1:55 ` Gao Xiang 2019-08-20 1:55 ` Gao Xiang 2019-08-20 1:55 ` Gao Xiang 2019-08-20 2:24 ` Chao Yu 2019-08-20 2:24 ` Chao Yu 2019-08-20 2:24 ` Chao Yu 2019-08-20 2:38 ` Qu Wenruo 2019-08-20 2:38 ` Qu Wenruo 2019-08-20 2:38 ` Qu Wenruo 2019-08-20 7:15 ` Chao Yu 2019-08-20 7:15 ` Chao Yu 2019-08-20 7:15 ` Chao Yu 2019-08-20 8:46 ` Qu Wenruo 2019-08-20 8:46 ` Qu Wenruo 2019-08-20 8:46 ` Qu Wenruo 2019-08-21 2:12 ` Chao Yu 2019-08-21 2:12 ` Chao Yu 2019-08-21 2:12 ` Chao Yu 2019-08-20 15:56 ` Theodore Y. Ts'o 2019-08-20 15:56 ` Theodore Y. Ts'o 2019-08-20 15:56 ` Theodore Y. Ts'o 2019-08-20 16:35 ` Gao Xiang 2019-08-20 16:35 ` Gao Xiang via Linux-erofs 2019-08-20 16:35 ` Gao Xiang 2019-08-21 0:51 ` Theodore Y. Ts'o 2019-08-21 0:51 ` Theodore Y. Ts'o 2019-08-21 0:51 ` Theodore Y. Ts'o 2019-08-21 1:34 ` Chao Yu 2019-08-21 1:34 ` Chao Yu 2019-08-21 1:48 ` Darrick J. Wong 2019-08-21 1:48 ` Darrick J. Wong 2019-08-21 1:48 ` Darrick J. Wong 2019-08-21 1:57 ` Chao Yu 2019-08-21 1:57 ` Chao Yu 2019-08-21 1:57 ` Chao Yu 2019-08-20 3:33 ` Miao Xie 2019-08-20 3:33 ` Miao Xie 2019-08-20 3:33 ` Miao Xie 2019-08-20 3:46 ` Gao Xiang 2019-08-20 3:46 ` Gao Xiang 2019-08-20 3:46 ` Gao Xiang 2019-08-20 6:04 ` Qu Wenruo 2019-08-20 6:04 ` Qu Wenruo 2019-08-20 6:04 ` Qu Wenruo 2019-08-20 6:22 ` Gao Xiang 2019-08-20 6:22 ` Gao Xiang 2019-08-20 6:22 ` Gao Xiang 2019-08-19 7:37 ` Richard Weinberger 2019-08-19 7:37 ` Richard Weinberger 2019-08-18 17:43 ` Theodore Y. Ts'o 2019-08-18 17:43 ` Theodore Y. Ts'o 2019-08-18 16:03 ` Gao Xiang 2019-08-18 16:03 ` Gao Xiang 2019-08-18 17:06 ` Richard Weinberger 2019-08-18 17:06 ` Richard Weinberger 2019-08-18 17:46 ` Theodore Y. Ts'o 2019-08-18 17:46 ` Theodore Y. Ts'o 2019-08-18 18:00 ` Richard Weinberger 2019-08-18 18:00 ` Richard Weinberger 2019-08-18 18:31 ` Gao Xiang 2019-08-18 18:31 ` Gao Xiang 2019-08-18 9:28 ` Gao Xiang 2019-08-18 9:28 ` Gao Xiang 2019-08-19 5:28 ` [PATCH] erofs: Use common kernel logging style Joe Perches 2019-08-19 5:28 ` Joe Perches 2019-08-19 5:52 ` Gao Xiang 2019-08-19 5:52 ` Gao Xiang 2019-08-19 5:47 ` Joe Perches 2019-08-19 5:47 ` Joe Perches 2019-08-19 6:08 ` Gao Xiang 2019-08-19 6:08 ` Gao Xiang
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=20190818005202.GA3088@hsiangkao-HP-ZHAN-66-Pro-G1 \ --to=hsiangkao@aol.com \ --cc=akpm@linux-foundation.org \ --cc=amir73il@gmail.com \ --cc=bluce.liguifu@huawei.com \ --cc=darrick.wong@oracle.com \ --cc=david@fromorbit.com \ --cc=devel@driverdev.osuosl.org \ --cc=dsterba@suse.cz \ --cc=fangwei1@huawei.com \ --cc=gaoxiang25@huawei.com \ --cc=gregkh@linuxfoundation.org \ --cc=hch@infradead.org \ --cc=jack@suse.cz \ --cc=jaegeuk@kernel.org \ --cc=linux-erofs@lists.ozlabs.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=miaoxie@huawei.com \ --cc=pavel@denx.de \ --cc=richard@nod.at \ --cc=sfr@canb.auug.org.au \ --cc=torvalds@linux-foundation.org \ --cc=tytso@mit.edu \ --cc=viro@zeniv.linux.org.uk \ --cc=yuchao0@huawei.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: linkBe 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.