Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <da6deb10-62e9-cbe6-e6f4-15f956e966b1@linaro.org>
Date:   Tue, 22 Mar 2022 10:42:27 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
To:     Ira Weiny <ira.weiny@intel.com>
Cc:     tytso@mit.edu, Andreas Dilger <adilger.kernel@dilger.ca>,
        Ritesh Harjani <riteshh@linux.ibm.com>,
        linux-ext4@vger.kernel.org, stable@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        syzbot+7a806094edd5d07ba029@syzkaller.appspotmail.com
References: <20220315215439.269122-1-tadeusz.struk@linaro.org>
 <Yjn7V3whEZ3UmJlF@iweiny-desk3>
From:   Tadeusz Struk <tadeusz.struk@linaro.org>
Subject: Re: [PATCH v2] ext4: check if offset+length is valid in fallocate
In-Reply-To: <Yjn7V3whEZ3UmJlF@iweiny-desk3>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Ira,
On 3/22/22 09:37, Ira Weiny wrote:
> On Tue, Mar 15, 2022 at 02:54:39PM -0700, Tadeusz Struk wrote:
>> Syzbot found an issue [1] in ext4_fallocate().
>> The C reproducer [2] calls fallocate(), passing size 0xffeffeff000ul,
>> and offset 0x1000000ul, which, when added together exceed the disk size,
>> and trigger a BUG in ext4_ind_remove_space() [3].
>> According to the comment doc in ext4_ind_remove_space() the 'end' block
>> parameter needs to be one block after the last block to remove.
>> In the case when the BUG is triggered it points to the last block on
>> a 4GB virtual disk image. This is calculated in
>> ext4_ind_remove_space() in [4].
>> This patch adds a check that ensure the length + offest to be
>> within the valid range and returns -ENOSPC error code in case
>> it is invalid.
> 
> Why is the check in vfs_fallocate() not working for this?
> 
> https://elixir.bootlin.com/linux/v5.17-rc8/source/fs/open.c#L300

Good question. From reading the comment:
https://elixir.bootlin.com/linux/v5.17/source/fs/ext4/file.c#L225

it is possible that, for the bitmap-format, the limit might be smaller
than the s_maxbytes.

But even for a extent-mapped file the offest+len needs to be within the
first to last-1 block range for fallocate(fd, FALLOC_FL_PUNCH_HOLE, ...)
If it points to the last one then it is invalid, no?

The check you pointed to in vfs code checks if offest+len goes beyond
maximal file size.

> Also why do other file systems not fail?  Is it because ext4 is special due to
> the end block needing to be one block after the last.  That seems to imply the
> last block can't be used or there is some off by one issue somewhere?

According to the comment in
https://elixir.bootlin.com/linux/v5.17/source/fs/ext4/indirect.c#L1214
it has to be one block after the last to be removed.

-- 
Thanks,
Tadeusz