Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1757179pxb; Sat, 2 Apr 2022 02:17:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDAa9ogxwFXgACxVxl1+Gy9JgCn8P7pxxinS3ZLM2YcTvc4yHmbDplATFPIacb7r74eN3t X-Received: by 2002:a50:9f64:0:b0:410:801c:4e2f with SMTP id b91-20020a509f64000000b00410801c4e2fmr24264773edf.179.1648891040291; Sat, 02 Apr 2022 02:17:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648891040; cv=none; d=google.com; s=arc-20160816; b=yCMLoQPTSnWeELQcgEeoM2qgB2Y70jLeD4KEQJjLAobHqHHP18wI8f58ZbO5wDm4uf pYsO9s4tdksARsE9h4qkNPB+F5P2nLMUULZjqp4pWWyyttuVVGaTxtx1MXtRZWbzbsY+ /PET3psGcgRUEjrNBesvlsMu4Nd4YP6EQIWHeSbSQfPpB5zRAPb3j3zUJYP1348r9G87 vjuqSiP9DK517tsE2XnPfAh1TXMnfdADWaJ4RCjlpDmSjNAkhLxOurTeYhghcDJUNNQe RUpHV0B20a5dyy53Gvfaj2diG1CtBe0fc/YtSapwMLz+ApaSdKmcfDooDVm8blP5IoG1 TRyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=p9t6Pq/1FxCVVbqJtOJthgB43FJ45dwItTm1qqJ1hpI=; b=XBicrzEuAi4qIp/n+tAwAepOu4Pp2T4bJCTHl/MAG0s2yQ5Tj02HP+A/vkZrzudNHX VMXU3FupcqpR5TibhA77riZwmb6RXlE+9lb7fx1GbYYCqLqDxmY7WLLp1DoaC+kRD6Lo s5iWlTs0LI2W+vP1Ua1TzbIGCYLFDRTX6rwrnhY5/sm8AYmc5bVUFMU+AKW3rFboeBhi a6VWwXwzJUc809GvDIAOguTXF6oNphrzxswIL+1xYwCjoKO6iiUmYKie8V5bhV74S4MV 0kCPPihHD0VF00vBjamAot7FelOWbO36VXJOWRwupLN0S4XbZAW2Q5t5xkKP/tFztkQh W8rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=k+DZFzBF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z15-20020a170906240f00b006df7cbdd0b7si664785eja.880.2022.04.02.02.16.55; Sat, 02 Apr 2022 02:17:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=k+DZFzBF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241215AbiCaUH3 (ORCPT + 99 others); Thu, 31 Mar 2022 16:07:29 -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-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: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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=b80bd9cf348aac724a4f4dff251800106d721331 LINK: [2] https://syzkaller.appspot.com/text?tag=ReproC&x=14ba0238700000 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 offset, loff_t length) struct super_block *sb = inode->i_sb; ext4_lblk_t first_block, stop_block; struct address_space *mapping = 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 = EXT4_SB(inode->i_sb); handle_t *handle; unsigned int credits; int ret = 0, ret2 = 0; @@ -4001,6 +4002,14 @@ int ext4_punch_hole(struct inode *inode, loff_t offset, loff_t length) offset; } + /* + * 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 = sbi->s_bitmap_maxbytes - inode->i_sb->s_blocksize; + if (offset + length > max_length) + length = max_length - offset; + if (offset & (sb->s_blocksize - 1) || (offset + length) & (sb->s_blocksize - 1)) { /* -- 2.35.1