From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-wr0-f196.google.com ([209.85.128.196]:43136 "EHLO
        mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S965577AbeFOKpg (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 15 Jun 2018 06:45:36 -0400
Received: by mail-wr0-f196.google.com with SMTP id d2-v6so9439792wrm.10
        for <linux-fsdevel@vger.kernel.org>; Fri, 15 Jun 2018 03:45:35 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <0e4fb819-706c-6028-704b-393919ce8b26@i-love.sakura.ne.jp>
References: <1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
 <20180509160658.c37bef542a8ee5245a13917b@linux-foundation.org>
 <201805092346.w49NkINl045657@www262.sakura.ne.jp> <20180509165321.3b2b1313fde0f007c1a5a015@linux-foundation.org>
 <9ef86114-02d6-b243-203d-fbbdab95a6fa@I-love.SAKURA.ne.jp>
 <CAK+_RLko_OCepN4FCmsaQPAKkt9JNGe8pNRK7SO-onhw5zCneA@mail.gmail.com>
 <CACT4Y+aFF4qCDT70Um-CR17bZc3UzL=hJYJsR0BmSvdPw7w_KQ@mail.gmail.com>
 <CAK+_RL=mNYahSkoMcaxcdyKGT=NX672fmAeb1=evfBZx1iqoAw@mail.gmail.com>
 <CACT4Y+Zmgjzwj8pgTRB2YD6HjcGHz8cCQn2OjcscHKLYUo8XcQ@mail.gmail.com>
 <CAK+_RLmxrdtxSxL-iVUfAgRAuSdC7hVV6QUZYxU5PDQUL-4nDg@mail.gmail.com>
 <f8e7cc6b-78d0-a03d-3d6e-3fe685a7feea@i-love.sakura.ne.jp>
 <CAK+_RLk3ntTB4aJgT9U3CctoYq581juzu=ZMNosN+pbJ5vBk0g@mail.gmail.com>
 <CAK+_RL=3k4LipYPixFf1HsTvHu-ebgZQy5oTJtDwh9NGjrSxig@mail.gmail.com>
 <CAK+_RLnJ7WtJBSy1SYqyshS3kKB59LTZoZxdtOmk-8eun-9BGg@mail.gmail.com> <0e4fb819-706c-6028-704b-393919ce8b26@i-love.sakura.ne.jp>
From: Tigran Aivazian <aivazian.tigran@gmail.com>
Date: Fri, 15 Jun 2018 11:45:34 +0100
Message-ID: <CAK+_RL=sKJWi+JLvUQJW3KW4_Px5vLdrRyBuaDdenbvuZ8bv-g@mail.gmail.com>
Subject: Re: [PATCH] bfs: add sanity check at bfs_fill_super().
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Dmitry Vyukov <dvyukov@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        syzbot <syzbot+71c6b5d68e91149fc8a4@syzkaller.appspotmail.com>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 14 June 2018 at 23:18, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2018/06/15 4:00, Tigran Aivazian wrote:
>> Ah, it turned out easier than I thought! The maximum number of inodes
>> of a BFS filesystem is 512, so an inode map cannot be longer than 65
>> bytes. Well, we can be generous and restrict imap_len to 128 and be
>> done with it :)
>>
>> Namely, if the calculated imap_len turns out to be greater than 128,
>> then something is definitely wrong and the filesystem image should be
>> rejected as corrupted.
>>
> So, the constraint is
>
>   if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
>       le32_to_cpu(bfs_sb->s_end) > What_is_the_number_here)
>
> you can write the fix yourself...

No, s_end has nothing to do with the number of inodes, it is to do
with the actual data blocks.

Yes, I am writing the fix myself and will test it under 4.17.1 to
which I switched my Ubuntu desktop just now.

Thanks,
Tigran