From: Ocean Chen via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: yuchao0@huawei.com, jaegeuk@kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v2] f2fs: avoid out-of-range memory access
Date: Mon, 8 Jul 2019 11:21:11 +0800 [thread overview]
Message-ID: <20190708032111.GA189070@google.com> (raw)
In-Reply-To: <65e4ad7b-ffbc-d5c9-9a0f-0532f4c4f5a9@huawei.com>
Hi YuChao,
Yes, we got externel researcher reports this security vulnerability.
And dump info is better when blk_off is invalid. I'll prepare the next
patch for it.
On Thu, Jul 04, 2019 at 03:11:27PM +0800, Chao Yu wrote:
> Hi Ocean,
>
> On 2019/7/3 23:03, Ocean Chen wrote:
> > Hi Yu Chao,
> >
> > The cur_data_segno only was checked in mount process. In terms of
> > security concern, it's better to check value before using it. I know the
>
> Could you explain more about security concern.. Do you get any report from user
> or tools that complaining f2fs issue/codes?
>
> I'm not against sanity check for basic core data of filesystem in run-time, but,
> in order to troubleshoot root cause of this issue we can trigger panic directly
> to dump more info under F2FS_CHECK_FS macro.
>
> So, maybe we can change as below?
>
> blk_off = le16_to_cpu(ckpt->cur_data_blkoff[i]);
> +if (blk_off > ENTRIES_IN_SUM) {
> + f2fs_bug_on(1);
> + f2fs_put_page(page, 1);
> + return -EFAULT;
> +}
>
> Thanks,
>
> > risk is low. IMHO, it can be safer.
> > BTW, I found we can only check blk_off before for loop instead of
> > checking 'j' in each iteratoin.
> >
> > On Wed, Jul 03, 2019 at 10:07:11AM +0800, Chao Yu wrote:
> >> Hi Ocean,
> >>
> >> If filesystem is corrupted, it should fail mount due to below check in
> >> f2fs_sanity_check_ckpt(), so we are safe in read_compacted_summaries() to access
> >> entries[0,blk_off], right?
> >>
> >> for (i = 0; i < NR_CURSEG_DATA_TYPE; i++) {
> >> if (le32_to_cpu(ckpt->cur_data_segno[i]) >= main_segs ||
> >> le16_to_cpu(ckpt->cur_data_blkoff[i]) >= blocks_per_seg)
> >> return 1;
> >>
> >> Thanks,
> >>
> >> On 2019/7/2 16:05, Ocean Chen wrote:
> >>> blk_off might over 512 due to fs corrupt.
> >>> Use ENTRIES_IN_SUM to protect invalid memory access.
> >>>
> >>> v2:
> >>> - fix typo
> >>> Signed-off-by: Ocean Chen <oceanchen@google.com>
> >>> ---
> >>> fs/f2fs/segment.c | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> >>> index 8dee063c833f..a5e8af0bd62e 100644
> >>> --- a/fs/f2fs/segment.c
> >>> +++ b/fs/f2fs/segment.c
> >>> @@ -3403,6 +3403,8 @@ static int read_compacted_summaries(struct f2fs_sb_info *sbi)
> >>>
> >>> for (j = 0; j < blk_off; j++) {
> >>> struct f2fs_summary *s;
> >>> + if (j >= ENTRIES_IN_SUM)
> >>> + return -EFAULT;
> >>> s = (struct f2fs_summary *)(kaddr + offset);
> >>> seg_i->sum_blk->entries[j] = *s;
> >>> offset += SUMMARY_SIZE;
> >>>
> > .
> >
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ocean Chen <oceanchen@google.com>
To: yuchao0@huawei.com, jaegeuk@kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] f2fs: avoid out-of-range memory access
Date: Mon, 8 Jul 2019 11:21:11 +0800 [thread overview]
Message-ID: <20190708032111.GA189070@google.com> (raw)
In-Reply-To: <65e4ad7b-ffbc-d5c9-9a0f-0532f4c4f5a9@huawei.com>
Hi YuChao,
Yes, we got externel researcher reports this security vulnerability.
And dump info is better when blk_off is invalid. I'll prepare the next
patch for it.
On Thu, Jul 04, 2019 at 03:11:27PM +0800, Chao Yu wrote:
> Hi Ocean,
>
> On 2019/7/3 23:03, Ocean Chen wrote:
> > Hi Yu Chao,
> >
> > The cur_data_segno only was checked in mount process. In terms of
> > security concern, it's better to check value before using it. I know the
>
> Could you explain more about security concern.. Do you get any report from user
> or tools that complaining f2fs issue/codes?
>
> I'm not against sanity check for basic core data of filesystem in run-time, but,
> in order to troubleshoot root cause of this issue we can trigger panic directly
> to dump more info under F2FS_CHECK_FS macro.
>
> So, maybe we can change as below?
>
> blk_off = le16_to_cpu(ckpt->cur_data_blkoff[i]);
> +if (blk_off > ENTRIES_IN_SUM) {
> + f2fs_bug_on(1);
> + f2fs_put_page(page, 1);
> + return -EFAULT;
> +}
>
> Thanks,
>
> > risk is low. IMHO, it can be safer.
> > BTW, I found we can only check blk_off before for loop instead of
> > checking 'j' in each iteratoin.
> >
> > On Wed, Jul 03, 2019 at 10:07:11AM +0800, Chao Yu wrote:
> >> Hi Ocean,
> >>
> >> If filesystem is corrupted, it should fail mount due to below check in
> >> f2fs_sanity_check_ckpt(), so we are safe in read_compacted_summaries() to access
> >> entries[0,blk_off], right?
> >>
> >> for (i = 0; i < NR_CURSEG_DATA_TYPE; i++) {
> >> if (le32_to_cpu(ckpt->cur_data_segno[i]) >= main_segs ||
> >> le16_to_cpu(ckpt->cur_data_blkoff[i]) >= blocks_per_seg)
> >> return 1;
> >>
> >> Thanks,
> >>
> >> On 2019/7/2 16:05, Ocean Chen wrote:
> >>> blk_off might over 512 due to fs corrupt.
> >>> Use ENTRIES_IN_SUM to protect invalid memory access.
> >>>
> >>> v2:
> >>> - fix typo
> >>> Signed-off-by: Ocean Chen <oceanchen@google.com>
> >>> ---
> >>> fs/f2fs/segment.c | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> >>> index 8dee063c833f..a5e8af0bd62e 100644
> >>> --- a/fs/f2fs/segment.c
> >>> +++ b/fs/f2fs/segment.c
> >>> @@ -3403,6 +3403,8 @@ static int read_compacted_summaries(struct f2fs_sb_info *sbi)
> >>>
> >>> for (j = 0; j < blk_off; j++) {
> >>> struct f2fs_summary *s;
> >>> + if (j >= ENTRIES_IN_SUM)
> >>> + return -EFAULT;
> >>> s = (struct f2fs_summary *)(kaddr + offset);
> >>> seg_i->sum_blk->entries[j] = *s;
> >>> offset += SUMMARY_SIZE;
> >>>
> > .
> >
next prev parent reply other threads:[~2019-07-08 3:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 8:05 [f2fs-dev] [PATCH v2] f2fs: avoid out-of-range memory access Ocean Chen via Linux-f2fs-devel
2019-07-02 8:05 ` Ocean Chen
2019-07-03 2:07 ` [f2fs-dev] " Chao Yu
2019-07-03 2:07 ` Chao Yu
2019-07-03 15:03 ` [f2fs-dev] " Ocean Chen via Linux-f2fs-devel
2019-07-03 15:03 ` Ocean Chen
2019-07-04 7:11 ` [f2fs-dev] " Chao Yu
2019-07-04 7:11 ` Chao Yu
2019-07-08 3:21 ` Ocean Chen via Linux-f2fs-devel [this message]
2019-07-08 3:21 ` Ocean Chen
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=20190708032111.GA189070@google.com \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=jaegeuk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oceanchen@google.com \
--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 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.