From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D9D1BA49 for ; Tue, 7 Mar 2023 18:35:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA1ADC4339B; Tue, 7 Mar 2023 18:35:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1678214149; bh=//03Omsn0zd6IxRBOjRByaNbgMQzFVQrt0YCCfyarVE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HCfS/SYpmFhFmXcFcc3rxwuwzKq5lCPvfnI6uVhSgTyfec66SPlQhrnkp/iSG5Bzp sfeYrBTMwvzhTXYSmxoxz/948MA8HCSELnMXTT31JYF/pRqod/xL6o+GIex29pupeu ReU3Dqj6x1GH8geLHGvGQZ/EPpNNm7+6fcmakyBE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot+60f291a24acecb3c2bd5@syzkaller.appspotmail.com, Jan Kara Subject: [PATCH 6.1 708/885] udf: Do not bother merging very long extents Date: Tue, 7 Mar 2023 18:00:42 +0100 Message-Id: <20230307170032.817581465@linuxfoundation.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230307170001.594919529@linuxfoundation.org> References: <20230307170001.594919529@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Jan Kara commit 53cafe1d6d8ef9f93318e5bfccc0d24f27d41ced upstream. When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together. CC: stable@vger.kernel.org Reported-by: syzbot+60f291a24acecb3c2bd5@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman --- fs/udf/inode.c | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-) --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -1094,23 +1094,8 @@ static void udf_merge_extents(struct ino blocksize - 1) >> blocksize_bits)))) { if (((li->extLength & UDF_EXTENT_LENGTH_MASK) + - (lip1->extLength & UDF_EXTENT_LENGTH_MASK) + - blocksize - 1) & ~UDF_EXTENT_LENGTH_MASK) { - lip1->extLength = (lip1->extLength - - (li->extLength & - UDF_EXTENT_LENGTH_MASK) + - UDF_EXTENT_LENGTH_MASK) & - ~(blocksize - 1); - li->extLength = (li->extLength & - UDF_EXTENT_FLAG_MASK) + - (UDF_EXTENT_LENGTH_MASK + 1) - - blocksize; - lip1->extLocation.logicalBlockNum = - li->extLocation.logicalBlockNum + - ((li->extLength & - UDF_EXTENT_LENGTH_MASK) >> - blocksize_bits); - } else { + (lip1->extLength & UDF_EXTENT_LENGTH_MASK) + + blocksize - 1) <= UDF_EXTENT_LENGTH_MASK) { li->extLength = lip1->extLength + (((li->extLength & UDF_EXTENT_LENGTH_MASK) +