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;
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Tadeusz Struk <tadeusz.struk@linaro.org>,
        linux-ext4@vger.kernel.org
Cc:     "Theodore Ts'o" <tytso@mit.edu>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org, Ritesh Harjani <riteshh@linux.ibm.com>,
        Andreas Dilger <adilger.kernel@dilger.ca>,
        syzbot+7a806094edd5d07ba029@syzkaller.appspotmail.com
Subject: Re: [PATCH v3] ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
Date:   Sun,  3 Apr 2022 10:53:17 -0400
Message-Id: <164899700423.964485.7890254685030914129.b4-ty@mit.edu>
In-Reply-To: <20220331200515.153214-1-tadeusz.struk@linaro.org>
References: <20220331200515.153214-1-tadeusz.struk@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 31 Mar 2022 13:05:15 -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
> bitmap_maxbytes for the inode. This triggers a BUG in
> ext4_ind_remove_space(). According to the comments in this function
> the 'end' parameter needs to be one block after the last block to be
> removed. In the case when the BUG is triggered it points to the last
> block. Modify the ext4_punch_hole() function and add constraint that
> caps the length to satisfy the one before laster block requirement.
> 
> [...]

Applied, thanks!

[1/1] ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
      commit: dfc99c5e84e46c610a7bf81dc4a3a126253be459

Best regards,
-- 
Theodore Ts'o <tytso@mit.edu>