Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2717155pxv; Sun, 11 Jul 2021 23:40:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz0+jIQY4/ofITPXiXnP3cBUoifw6OpFHsmg9Lb0L7ebbE4Qc8Z872gRfFgJx0jesqy4kuZ X-Received: by 2002:a50:d508:: with SMTP id u8mr63756786edi.223.1626072017849; Sun, 11 Jul 2021 23:40:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626072017; cv=none; d=google.com; s=arc-20160816; b=SUiGt4WvEm3cmoBwAqNIPSn6IerhV6M0pzhPVclqhf+450ep53fiQecwEOQBCIbC3U dSquvRLIOsFBifuc2gx+yNz9SgiKUVKBJ9q8mM/tIo5DyePVUmdlRO90npePeW/Mv+qA b5fsRXDQiXdtzRC0pIAnu6QnxpjPf680iS87E0v3MN0cNKnqYfs8axRZ4pD4HQpGMizF GGh9YURrjVYZWmN0K8F9vve32YF7+M25jtCg1tskWs/hiAeCA/CnAHh3jIjQUQWLoVYb 7Zl5uCiuya+i0awYgiWQmAnxEGEea5LD89xvXdO+eL5ALfp7+wEuV8nMhpwVHRCZU0Oz HOeg== 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=tTXaAOmSbcV9rKVht3l7h2JR4BEQtUaVfO2Wb3MtSpA=; b=t1NzFAoAOBhwBybaQ3nftogRS+IbMwdZvuGsjiW24wV+V90TV981d5Pg0cX9EXfmMr JzDceNpF/Zw7zpLwPE3qZexukSIXuxI71qTCY30z8nKQVRhW6RfAm2ONN2RZClDe2ztk zlClPQa6Yk1fJn+L9qRHzcRolu+8cp94kE3ybdhEI4sYBuT2xkfblbTb7PhjjVxyhKtp 22N2Ee2oTsHODCR9GzHPKpVaCkvjOLzkUvKn2DmiVfotRUPeLVnb7fCycPY4IKAUcihk 94JJ1iyZfPvY29UdAY7fxCwzzqv03y7QQ8ISjoAuOUFCc/d9LsRzK8XEN8tXmribIhuE uf2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=JdaZMs6x; 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 b1si19486930ejb.600.2021.07.11.23.39.55; Sun, 11 Jul 2021 23:40:17 -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=JdaZMs6x; 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 S237848AbhGLGlD (ORCPT + 99 others); Mon, 12 Jul 2021 02:41:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:55532 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236998AbhGLGc0 (ORCPT ); Mon, 12 Jul 2021 02:32:26 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 96B2E60551; Mon, 12 Jul 2021 06:29:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626071378; bh=wmqnq9Vp+80gBd6WB5AOLCgk5SyK0FIL3EKx9C//Qxk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JdaZMs6xDGqQNno0ij0W4Jt1TlZyZyJJ4w943TZsBN18F7HobhWPlQFtRvBGGbq6B xclqTZ0LiRIKSI2ka5yQzNyXEe4CUG/ElbCS8mUMSNW9EvG5GZsyeVRbG6LQy/mcOy v2xg/axOFRztQAV4qbbfHZRJ4sDDRxRzvJlT6sL8= 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.10 044/593] ext4: fix overflow in ext4_iomap_alloc() Date: Mon, 12 Jul 2021 08:03:24 +0200 Message-Id: <20210712060847.998655270@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210712060843.180606720@linuxfoundation.org> References: <20210712060843.180606720@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 @@ -3419,7 +3419,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;