From mboxrd@z Thu Jan 1 00:00:00 1970 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 49E52C6FA99 for ; Fri, 10 Mar 2023 14:11:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231931AbjCJOLP (ORCPT ); Fri, 10 Mar 2023 09:11:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231778AbjCJOKh (ORCPT ); Fri, 10 Mar 2023 09:10:37 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26A141184F9 for ; Fri, 10 Mar 2023 06:10:28 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B9B7D617B4 for ; Fri, 10 Mar 2023 14:10:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD8B7C4339B; Fri, 10 Mar 2023 14:10:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1678457427; bh=G3s1v7hp0nHzMqtrFwH/DPZEXwDj67FX7Dpdq62oZ7U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1JgU293AzGBuuyWLH1k+BZXjw5gl1XywngwmBEQ8QIAaKqGFilTPQbUIRsOLiUNH9 TwcRnG40pfsXN8Rc26r8IfMZ6S5IOO64Qxlwd6pQLefhLhMa6FxzilJNJu2UIrSjFd +7rYa2xzivr/bfK2K0VDEJ1IFiF3xWUfm+M1gMIk= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Zhong Jinghua , Chaitanya Kulkarni , Jens Axboe , Sasha Levin Subject: [PATCH 6.1 103/200] loop: loop_set_status_from_info() check before assignment Date: Fri, 10 Mar 2023 14:38:30 +0100 Message-Id: <20230310133720.265704732@linuxfoundation.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230310133717.050159289@linuxfoundation.org> References: <20230310133717.050159289@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Zhong Jinghua [ Upstream commit 9f6ad5d533d1c71e51bdd06a5712c4fbc8768dfa ] In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should be checked before reassignment, because if an overflow error occurs, the original correct value will be changed to the wrong value, and it will not be changed back. More, the original patch did not solve the problem, the value was set and ioctl returned an error, but the subsequent io used the value in the loop driver, which still caused an alarm: loop_handle_cmd do_req_filebacked loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset; lo_rw_aio cmd->iocb.ki_pos = pos Fixes: c490a0b5a4f3 ("loop: Check for overflow while configuring loop") Signed-off-by: Zhong Jinghua Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20230221095027.3656193-1-zhongjinghua@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- drivers/block/loop.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index df628e30bca41..981464e561df1 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -977,13 +977,13 @@ loop_set_status_from_info(struct loop_device *lo, return -EINVAL; } + /* Avoid assigning overflow values */ + if (info->lo_offset > LLONG_MAX || info->lo_sizelimit > LLONG_MAX) + return -EOVERFLOW; + lo->lo_offset = info->lo_offset; lo->lo_sizelimit = info->lo_sizelimit; - /* loff_t vars have been assigned __u64 */ - if (lo->lo_offset < 0 || lo->lo_sizelimit < 0) - return -EOVERFLOW; - memcpy(lo->lo_file_name, info->lo_file_name, LO_NAME_SIZE); lo->lo_file_name[LO_NAME_SIZE-1] = 0; lo->lo_flags = info->lo_flags; -- 2.39.2