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 16:45:25 +0800 [thread overview]
Message-ID: <20190818084521.GA17909@hsiangkao-HP-ZHAN-66-Pro-G1> (raw)
In-Reply-To: <1405781266.69008.1566116210649.JavaMail.zimbra@nod.at>
On Sun, Aug 18, 2019 at 10:16:50AM +0200, Richard Weinberger wrote:
> ----- Urspr?ngliche Mail -----
> >> 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.
>
> This is no excuse to redo all these bugs. :-)
I agree with you, but what can we do now is trying our best to fuzz
all the fields.
So, what is your opinion about EROFS?
>
> I know that many in-kernel filesystems trust the disk ultimately, this is a
> problem and huge attack vector.
I EROFS already has many error handing paths to recover corrupted images,
and your discovery is a bug out of one error handing path miswritten by me.
I cannot make a guarantee that all the new things (every new kernel version
will introduce new feature / new code) are bug-free since I am not a machine
or code parser.
My answer about this EROFS will be more stable with our development, we have
a dedicated team with paid job, and since we currently use EROFS on the top of
dm-verity for current Android, which will keep us from corrupted images.
But yes, we will focus on fuzzing all the images for generic usages,
and we will backport all these patches to old stable versions.
Thanks,
Gao Xiang
>
> Thanks,
> //richard
next prev parent reply other threads:[~2019-08-18 8:45 UTC|newest]
Thread overview: 72+ 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 21:19 ` Richard Weinberger
2019-08-17 22:07 ` Gao Xiang
2019-08-17 23:25 ` Richard Weinberger
2019-08-17 23:38 ` Gao Xiang
2019-08-18 0:04 ` Gao Xiang
2019-08-18 0:52 ` Gao Xiang
2019-08-18 8:16 ` Richard Weinberger
2019-08-18 8:45 ` Gao Xiang [this message]
2019-08-18 9:03 ` Richard Weinberger
2019-08-18 9:09 ` Greg Kroah-Hartman
2019-08-18 9:21 ` Richard Weinberger
2019-08-18 10:12 ` Chao Yu
2019-08-18 15:11 ` Theodore Y. Ts'o
2019-08-18 15:58 ` Christoph Hellwig
2019-08-18 16:16 ` Eric Biggers
2019-08-18 16:22 ` Christoph Hellwig
2019-08-18 16:33 ` Gao Xiang
2019-08-18 17:29 ` Eric Biggers
2019-08-18 17:47 ` Christoph Hellwig
2019-08-18 18:16 ` Gao Xiang
2019-08-18 20:14 ` Gao Xiang
2019-08-19 7:35 ` Richard Weinberger
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 ` [PATCH 1/6] staging: erofs: some compressed cluster should be submitted for corrupted images Gao Xiang
2019-08-19 14:36 ` 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 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 14:40 ` Chao Yu
2019-08-19 10:34 ` [PATCH 4/6] staging: erofs: avoid loop in submit chains Gao Xiang
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 14:57 ` Chao Yu
2019-08-21 2:19 ` Greg Kroah-Hartman
2019-08-21 14:01 ` [PATCH v2 " Gao Xiang
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 14:58 ` Chao Yu
2019-08-19 16:09 ` [PATCH] erofs: move erofs out of staging Darrick J. Wong
2019-08-19 20:30 ` Gao Xiang
2019-08-20 0:55 ` Qu Wenruo
2019-08-20 1:55 ` Gao Xiang
2019-08-20 2:24 ` Chao Yu
2019-08-20 2:38 ` Qu Wenruo
2019-08-20 7:15 ` Chao Yu
2019-08-20 8:46 ` Qu Wenruo
2019-08-21 2:12 ` Chao Yu
2019-08-20 15:56 ` Theodore Y. Ts'o
2019-08-20 16:35 ` Gao Xiang
2019-08-21 0:51 ` Theodore Y. Ts'o
2019-08-21 1:34 ` Chao Yu
2019-08-21 1:48 ` Darrick J. Wong
2019-08-21 1:57 ` Chao Yu
2019-08-20 3:33 ` Miao Xie
2019-08-20 3:46 ` Gao Xiang
2019-08-20 6:04 ` Qu Wenruo
2019-08-20 6:22 ` Gao Xiang
2019-08-19 7:37 ` Richard Weinberger
2019-08-18 17:43 ` Theodore Y. Ts'o
2019-08-18 16:03 ` Gao Xiang
2019-08-18 17:06 ` Richard Weinberger
2019-08-18 17:46 ` Theodore Y. Ts'o
2019-08-18 18:00 ` Richard Weinberger
2019-08-18 18:31 ` 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:52 ` Gao Xiang
2019-08-19 5:47 ` Joe Perches
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=20190818084521.GA17909@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: 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).