Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2833597pxv; Mon, 12 Jul 2021 03:05:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzhe5TTn17Cz6iq8XpW0OUAc30BMgd2hgqJghFvqbXtMbdDbl8pPJFenX5ZUl994q/Ku3lL X-Received: by 2002:a92:c644:: with SMTP id 4mr16191612ill.246.1626084318972; Mon, 12 Jul 2021 03:05:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626084318; cv=none; d=google.com; s=arc-20160816; b=LUq/Jj8X7Ln3+xNJFEgdmxEYzHhJQ5KFTmZtkh5iRzueC1/C4tjumrg7VhNCHmO/U9 4xwevOzDfDbnE40ETvcfSL8kSg6uPYZMZoekfjofl7mAY9TpXTDQMS5Mi76nWlBzlg+A KNfOJYcUCwi+FDj0nwE5fa+ocZ9ermszK7Sw2X+JUzEljnGvD2hSIYGXbppuB9jNcwhq cMN6IWLtEw5Iza8AfA1/nWk4rOgaVOAsueVrvWq/Lh3aMt6i+mTzqEin3y7nHnWPRnpD 79QwJ7Ej4IIpu73IPQ5+KybhW84Ohk65FkbgolbPBnLWzroNb/QLjonlxdjcsqqHf2It 6OAw== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=opppBpekuVTK6wsaLFPtFao5T5GsYdXkQAYQCig8CPk=; b=KCOkwSplCfUIAPt7+59kHqCI9eZ8kmuEy38lFCngxoigUnbAALiFMJE3KlmL99bQYC 94GLMnLHnOgnnx1QRMjE2k6p+UYWZJ7FRtA9TBIoSKzhdES/hGC+CZeRU39W9wvdZE4C 6Bri7GTcEXcsm3jQ0fuuBgMilmF0G789BBEOxKInr2YTuLLyC/LAZe12ues7gvZcrczs 13wN8AYvEnmVLgwsQBuaFINr+a9zPZm/pJpwrea4IviuGlBa2N1Iql6Rjb+m9Fdsb7pv McLCAUsSKS5bwpZyFJigw3Z/9SVYOcclFoaXJrdLoyFwLRpxeXHvB+S50f7OaQ1Hk3rR I2pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=FxsMMJux; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x12si16240925ilm.5.2021.07.12.03.05.07; Mon, 12 Jul 2021 03:05:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=FxsMMJux; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344982AbhGLHYh (ORCPT + 99 others); Mon, 12 Jul 2021 03:24:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:58140 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239307AbhGLG5c (ORCPT ); Mon, 12 Jul 2021 02:57:32 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 45D4F61248; Mon, 12 Jul 2021 06:54:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626072876; bh=DwHXodav4ShwyZ/zm5t4mBkvd/xVCgOhbEi9L4KjvmU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FxsMMJux5wLdrK6WZUTiAg6hZt5YoVgFPT+v08K4IDmuID0EMFOvcgTS4jqCh0s4Y U1GkBjOcqFJCYj+ty0qzFFiIyzLur86WAI3aSqWaMp/kW8cc3mitUsaKliG7gtt2kG yQawCYjNKQiRD5V20sUjuo4ByO6MMFwiMVFr/x0Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Jan Kara , Theodore Tso Subject: [PATCH 5.12 051/700] ext4: fix overflow in ext4_iomap_alloc() Date: Mon, 12 Jul 2021 08:02:14 +0200 Message-Id: <20210712060931.899255522@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210712060924.797321836@linuxfoundation.org> References: <20210712060924.797321836@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jan Kara commit d0b040f5f2557b2f507c01e88ad8cff424fdc6a9 upstream. A code in iomap alloc may overflow block number when converting it to byte offset. Luckily this is mostly harmless as we will just use more expensive method of writing using unwritten extents even though we are writing beyond i_size. Cc: stable@kernel.org Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20210412102333.2676-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3420,7 +3420,7 @@ retry: * i_disksize out to i_size. This could be beyond where direct I/O is * happening and thus expose allocated blocks to direct I/O reads. */ - else if ((map->m_lblk * (1 << blkbits)) >= i_size_read(inode)) + else if (((loff_t)map->m_lblk << blkbits) >= i_size_read(inode)) m_flags = EXT4_GET_BLOCKS_CREATE; else if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) m_flags = EXT4_GET_BLOCKS_IO_CREATE_EXT;