Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <EEF59072-2BFA-4757-92D7-7A9B6CF134EC@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_A90B0E2B-1702-46BA-A230-75E02BBAFE54";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH 1/2] ext4: check if directory block is within i_size
Date:   Sat, 9 Jul 2022 11:31:44 -0600
In-Reply-To: <20220704142721.157985-1-lczerner@redhat.com>
Cc:     Ext4 Developers List <linux-ext4@vger.kernel.org>,
        Theodore Ts'o <tytso@mit.edu>, stable@vger.kernel.org
To:     Lukas Czerner <lczerner@redhat.com>
References: <20220704142721.157985-1-lczerner@redhat.com>
Precedence: bulk


--Apple-Mail=_A90B0E2B-1702-46BA-A230-75E02BBAFE54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jul 4, 2022, at 8:27 AM, Lukas Czerner <lczerner@redhat.com> wrote:
>=20
> Currently ext4 directory handling code implicitly assumes that the
> directory blocks are always within the i_size. In fact ext4_append()
> will attempt to allocate next directory block based solely on i_size =
and
> the i_size is then appropriately increased after a successful
> allocation.
>=20
> However, for this to work it requires i_size to be correct. If, for =
any
> reason, the directory inode i_size is corrupted in a way that the
> directory tree refers to a valid directory block past i_size, we could
> end up corrupting parts of the directory tree structure by overwriting
> already used directory blocks when modifying the directory.
>=20
> Fix it by catching the corruption early in __ext4_read_dirblock().
>=20
> Signed-off-by: Lukas Czerner <lczerner@redhat.com>

Reviewed-by: Andreas Dilger <adilger@dilger.ca>

> Addresses Red-Hat-Bugzilla: #2070205
> Cc: stable@vger.kernel.org
> ---
> fs/ext4/namei.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>=20
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index db4ba99d1ceb..cf460aa4f81d 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -110,6 +110,13 @@ static struct buffer_head =
*__ext4_read_dirblock(struct inode *inode,
> 	struct ext4_dir_entry *dirent;
> 	int is_dx_block =3D 0;
>=20
> +	if (block >=3D inode->i_size) {
> +		ext4_error_inode(inode, func, line, block,
> +		       "Attempting to read directory block (%u) that is =
past i_size (%llu)",
> +		       block, inode->i_size);
> +		return ERR_PTR(-EFSCORRUPTED);
> +	}
> +
> 	if (ext4_simulate_fail(inode->i_sb, EXT4_SIM_DIRBLOCK_EIO))
> 		bh =3D ERR_PTR(-EIO);
> 	else
> --
> 2.35.3
>=20


Cheers, Andreas


--Apple-Mail=_A90B0E2B-1702-46BA-A230-75E02BBAFE54
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmLJu4EACgkQcqXauRfM
H+BPfw/9FT299eRUI735N4gf9Ox11RqcFsE2l/Norm1oi0Gn09FT/MKqtr5wDI80
YunuxWNcw3WDT686PsEWIcxlBaoFYeDQ0vE76bWb5BUHJbUCqOV42uTM+P3DUji8
pMntepS4plKLktMoI1jB0u9+QxM6jy0sKr6r3kPWuyQscCvCCpzvxPsDPuBUThmz
fZlwSmR1Jrc+yhSZWoesg22w+XkQ+Qd0GG3NNLV6tumQYLSkBQoZGiqaFEwJ8Fpv
K3pxi168aoLQDckBRzNTIQJdPC+XvqBUL+JMDnG+hJt3QDWFSP2Nnkt7IYQ5fqpr
3z45Be6Eilo5k3Xnb5tby6khsTNyojuTzceGXRpiATafScTHO1iHHLsZzxAscd2+
6kTZoWbVSaGeLJ8bQIWMUlJQDFVMTq5Q31bnMAzyZpn2SLzE+xxoswkXgG9LvXUI
p4tltNfAzUScHKNK87hWf+8zMZr9QL9MhmZFECM4rFKcdMO3I6uz4yQV5O1W/77d
qi4R+HD2iWz645HFKFLQbGNL4LZf1bBPw1jkqiEmowj2CKOq+gMUUtovxdUbKk+R
73T7BbywYNWWul0KbMuf5pC8zvpLhfjEOfHbdSrKJtsmqMSx2r7NKTGnJ4DfvY2e
VyHTYWRd7BGa9PA4lC22tLl8fBwAzaGC8UK8dZz8sGdV3ksdVac=
=/Ts3
-----END PGP SIGNATURE-----

--Apple-Mail=_A90B0E2B-1702-46BA-A230-75E02BBAFE54--