[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220603173819.194392585@linuxfoundation.org>
Date: Fri, 3 Jun 2022 19:43:01 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Christoph Hellwig <hch@....de>,
Amir Goldstein <amir73il@...il.com>
Subject: [PATCH 5.10 16/53] xfs: detect overflows in bmbt records
From: "Darrick J. Wong" <darrick.wong@...cle.com>
commit acf104c2331c1ba2a667e65dd36139d1555b1432 upstream.
Detect file block mappings with a blockcount that's either so large that
integer overflows occur or are zero, because neither are valid in the
filesystem. Worse yet, attempting directory modifications causes the
iext code to trip over the bmbt key handling and takes the filesystem
down. We can fix most of this by preventing the bad metadata from
entering the incore structures in the first place.
Found by setting blockcount=0 in a directory data fork mapping and
watching the fireworks.
Signed-off-by: Darrick J. Wong <darrick.wong@...cle.com>
Reviewed-by: Christoph Hellwig <hch@....de>
Signed-off-by: Amir Goldstein <amir73il@...il.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
fs/xfs/libxfs/xfs_bmap.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -6229,6 +6229,11 @@ xfs_bmap_validate_extent(
xfs_fsblock_t endfsb;
bool isrt;
+ if (irec->br_startblock + irec->br_blockcount <= irec->br_startblock)
+ return __this_address;
+ if (irec->br_startoff + irec->br_blockcount <= irec->br_startoff)
+ return __this_address;
+
isrt = XFS_IS_REALTIME_INODE(ip);
endfsb = irec->br_startblock + irec->br_blockcount - 1;
if (isrt && whichfork == XFS_DATA_FORK) {
Powered by blists - more mailing lists