From nobody Fri Jun 19 17:13:37 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B11B7C433F5 for ; Thu, 31 Mar 2022 20:05:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241219AbiCaUHa (ORCPT ); Thu, 31 Mar 2022 16:07:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229923AbiCaUH2 (ORCPT ); Thu, 31 Mar 2022 16:07:28 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC78D1905AF for ; Thu, 31 Mar 2022 13:05:40 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id o68-20020a17090a0a4a00b001c686a48263so3571718pjo.1 for ; Thu, 31 Mar 2022 13:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=p9t6Pq/1FxCVVbqJtOJthgB43FJ45dwItTm1qqJ1hpI=; b=k+DZFzBF4OXV/isOqu1fX+iYt/dbsfQpHxFsvVwXaosR6G0JGbByOJaOHyc5vCKVQr ltQm1edsWc4pHVXEoUwjDXuAleaSO3swIpZWeZ9/kFXxLJd9Slgm5PN1ON71WDsudY5I zT0QBDf0T6vMRkOCin7JC9IAXWiGIMksc68srEOT0k4+GxMULM4NpDia06MvLmpeZsCK R8d+M/t8ojbNFDdL0jJ9RYldFJ0LRimtfwfvC0KEQUlAvFn8nJ3S+NenOxBg4YxJC7vh mF7fOrFNOoEumhyEiaOoQ7q1yOj4Rx/ltc57kDtrRkfd6BpGEEGMCSJoUvpIGcN2QQml 5TnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=p9t6Pq/1FxCVVbqJtOJthgB43FJ45dwItTm1qqJ1hpI=; b=OoR8uJRkwJC+IvLZSw682t9jGJVtmWwhEQzH3aDKH6wjL3t4mVEIBGSUq6GA51ODUp ZT3cZRF/NJvjVFGJ7qzHCZm+WX1aRfQlzzC54/5O2inQvHhVLe9pREZ3YbZfhzOkfhLV SDnQoh6/rMQg82lroSJnQhRhOJw9Bil+8v5OLNBLBbqjltmytWSfCBf+HEg/FhPHDBG6 PEraettwG1YLHbyYQDIQcLa5HSAXZtDydDTDrKMpq1OGvCM8Nwp3Fq76pKptAx0/JvcY yOgM9qiMzSyunn498hwWebIm8KwHJpmSwL2jIjmj6KwPibs/2fRh/jmsr+JScL+B6OfH GyZQ== X-Gm-Message-State: AOAM532Z8rMR57iAzoAhPvWJVzEpzVxS7Rfor918bfeGYoA4qUQw2z+C xiGScBtkwmiErpSheHtTubH4CdyNb4jlv9+k X-Google-Smtp-Source: ABdhPJx+odBnk0xoMo0XR3TevKAR/mX56Y1ppZhg4q4Gj2inIRQlWGCUsTvVGClo1qK2sdWjNiDnuQ== X-Received: by 2002:a17:90a:488c:b0:1c7:b62e:8e8c with SMTP id b12-20020a17090a488c00b001c7b62e8e8cmr7869098pjh.157.1648757140327; Thu, 31 Mar 2022 13:05:40 -0700 (PDT) Received: from localhost.localdomain ([50.39.160.154]) by smtp.gmail.com with ESMTPSA id v24-20020a634818000000b0036407db4728sm179053pga.26.2022.03.31.13.05.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 13:05:39 -0700 (PDT) From: Tadeusz Struk To: linux-ext4@vger.kernel.org Cc: Tadeusz Struk , Theodore Ts'o , Andreas Dilger , Ritesh Harjani , stable@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+7a806094edd5d07ba029@syzkaller.appspotmail.com Subject: [PATCH v3] ext4: limit length to bitmap_maxbytes - blocksize in punch_hole Date: Thu, 31 Mar 2022 13:05:15 -0700 Message-Id: <20220331200515.153214-1-tadeusz.struk@linaro.org> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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. LINK: [1] https://syzkaller.appspot.com/bug?id=3Db80bd9cf348aac724a4f4dff25= 1800106d721331 LINK: [2] https://syzkaller.appspot.com/text?tag=3DReproC&x=3D14ba0238700000 Cc: Theodore Ts'o Cc: Andreas Dilger Cc: Ritesh Harjani Cc: Cc: Cc: Fixes: a4bb6b64e39a ("ext4: enable "punch hole" functionality") Reported-by: syzbot+7a806094edd5d07ba029@syzkaller.appspotmail.com Signed-off-by: Tadeusz Struk -- v3: Modify the length instead of returning an error. v2: Change sbi->s_blocksize to inode->i_sb->s_blocksize in maxlength computation. --- fs/ext4/inode.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 1ce13f69fbec..60bf31765d07 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3958,7 +3958,8 @@ int ext4_punch_hole(struct inode *inode, loff_t offse= t, loff_t length) struct super_block *sb =3D inode->i_sb; ext4_lblk_t first_block, stop_block; struct address_space *mapping =3D inode->i_mapping; - loff_t first_block_offset, last_block_offset; + loff_t first_block_offset, last_block_offset, max_length; + struct ext4_sb_info *sbi =3D EXT4_SB(inode->i_sb); handle_t *handle; unsigned int credits; int ret =3D 0, ret2 =3D 0; @@ -4001,6 +4002,14 @@ int ext4_punch_hole(struct inode *inode, loff_t offs= et, loff_t length) offset; } =20 + /* + * For punch hole the length + offset needs to be within one block + * before last range. Adjust the length if it goes beyond that limit. + */ + max_length =3D sbi->s_bitmap_maxbytes - inode->i_sb->s_blocksize; + if (offset + length > max_length) + length =3D max_length - offset; + if (offset & (sb->s_blocksize - 1) || (offset + length) & (sb->s_blocksize - 1)) { /* --=20 2.35.1