From: Christoph Hellwig <hch@lst.de>
To: stable@vger.kernel.org
Cc: linux-xfs@vger.kernel.org, Eric Sandeen <sandeen@redhat.com>,
"Darrick J . Wong" <darrick.wong@oracle.com>
Subject: [PATCH 09/25] xfs: handle array index overrun in xfs_dir2_leaf_readbuf()
Date: Sat, 3 Jun 2017 15:18:20 +0200 [thread overview]
Message-ID: <20170603131836.26661-10-hch@lst.de> (raw)
In-Reply-To: <20170603131836.26661-1-hch@lst.de>
From: Eric Sandeen <sandeen@redhat.com>
commit 023cc840b40fad95c6fe26fff1d380a8c9d45939 upstream.
Carlos had a case where "find" seemed to start spinning
forever and never return.
This was on a filesystem with non-default multi-fsb (8k)
directory blocks, and a fragmented directory with extents
like this:
0:[0,133646,2,0]
1:[2,195888,1,0]
2:[3,195890,1,0]
3:[4,195892,1,0]
4:[5,195894,1,0]
5:[6,195896,1,0]
6:[7,195898,1,0]
7:[8,195900,1,0]
8:[9,195902,1,0]
9:[10,195908,1,0]
10:[11,195910,1,0]
11:[12,195912,1,0]
12:[13,195914,1,0]
...
i.e. the first extent is a contiguous 2-fsb dir block, but
after that it is fragmented into 1 block extents.
At the top of the readdir path, we allocate a mapping array
which (for this filesystem geometry) can hold 10 extents; see
the assignment to map_info->map_size. During readdir, we are
therefore able to map extents 0 through 9 above into the array
for readahead purposes. If we count by 2, we see that the last
mapped index (9) is the first block of a 2-fsb directory block.
At the end of xfs_dir2_leaf_readbuf() we have 2 loops to fill
more readahead; the outer loop assumes one full dir block is
processed each loop iteration, and an inner loop that ensures
that this is so by advancing to the next extent until a full
directory block is mapped.
The problem is that this inner loop may step past the last
extent in the mapping array as it tries to reach the end of
the directory block. This will read garbage for the extent
length, and as a result the loop control variable 'j' may
become corrupted and never fail the loop conditional.
The number of valid mappings we have in our array is stored
in map->map_valid, so stop this inner loop based on that limit.
There is an ASSERT at the top of the outer loop for this
same condition, but we never made it out of the inner loop,
so the ASSERT never fired.
Huge appreciation for Carlos for debugging and isolating
the problem.
Debugged-and-analyzed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Tested-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
fs/xfs/xfs_dir2_readdir.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_dir2_readdir.c b/fs/xfs/xfs_dir2_readdir.c
index 6645a221bf8e..ba95846f8f8a 100644
--- a/fs/xfs/xfs_dir2_readdir.c
+++ b/fs/xfs/xfs_dir2_readdir.c
@@ -394,6 +394,7 @@ xfs_dir2_leaf_readbuf(
/*
* Do we need more readahead?
+ * Each loop tries to process 1 full dir blk; last may be partial.
*/
blk_start_plug(&plug);
for (mip->ra_index = mip->ra_offset = i = 0;
@@ -425,9 +426,14 @@ xfs_dir2_leaf_readbuf(
}
/*
- * Advance offset through the mapping table.
+ * Advance offset through the mapping table, processing a full
+ * dir block even if it is fragmented into several extents.
+ * But stop if we have consumed all valid mappings, even if
+ * it's not yet a full directory block.
*/
- for (j = 0; j < geo->fsbcount; j += length ) {
+ for (j = 0;
+ j < geo->fsbcount && mip->ra_index < mip->map_valid;
+ j += length ) {
/*
* The rest of this extent but not more than a dir
* block.
--
2.11.0
next prev parent reply other threads:[~2017-06-03 13:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-03 13:18 4.9-stable updates for XFS Christoph Hellwig
2017-06-03 13:18 ` [PATCH 01/25] xfs: verify inline directory data forks Christoph Hellwig
2017-06-05 14:04 ` Greg KH
2017-06-05 14:04 ` Greg KH
2017-06-03 13:18 ` [PATCH 02/25] xfs: rework the inline directory verifiers Christoph Hellwig
2017-06-05 14:06 ` Greg KH
2017-06-05 14:37 ` Christoph Hellwig
2017-06-03 13:18 ` [PATCH 03/25] xfs: fix kernel memory exposure problems Christoph Hellwig
2017-06-03 13:18 ` [PATCH 04/25] xfs: use dedicated log worker wq to avoid deadlock with cil wq Christoph Hellwig
2017-06-03 13:18 ` [PATCH 05/25] xfs: fix over-copying of getbmap parameters from userspace Christoph Hellwig
2017-06-03 13:18 ` [PATCH 06/25] xfs: actually report xattr extents via iomap Christoph Hellwig
2017-06-03 13:18 ` [PATCH 07/25] xfs: drop iolock from reclaim context to appease lockdep Christoph Hellwig
2017-06-03 13:18 ` [PATCH 08/25] xfs: fix integer truncation in xfs_bmap_remap_alloc Christoph Hellwig
2017-06-03 13:18 ` Christoph Hellwig [this message]
2017-06-03 13:18 ` [PATCH 10/25] xfs: prevent multi-fsb dir readahead from reading random blocks Christoph Hellwig
2017-06-03 13:18 ` [PATCH 11/25] xfs: fix up quotacheck buffer list error handling Christoph Hellwig
2017-06-03 13:18 ` [PATCH 12/25] xfs: support ability to wait on new inodes Christoph Hellwig
2017-06-03 13:18 ` [PATCH 13/25] xfs: update ag iterator to support " Christoph Hellwig
2017-06-03 13:18 ` [PATCH 14/25] xfs: wait on new inodes during quotaoff dquot release Christoph Hellwig
2017-06-03 13:18 ` [PATCH 15/25] xfs: reserve enough blocks to handle btree splits when remapping Christoph Hellwig
2017-06-03 13:18 ` [PATCH 16/25] xfs: fix use-after-free in xfs_finish_page_writeback Christoph Hellwig
2017-06-03 13:18 ` [PATCH 17/25] xfs: fix indlen accounting error on partial delalloc conversion Christoph Hellwig
2017-06-03 13:18 ` [PATCH 18/25] xfs: BMAPX shouldn't barf on inline-format directories Christoph Hellwig
2017-06-03 13:18 ` [PATCH 19/25] xfs: bad assertion for delalloc an extent that start at i_size Christoph Hellwig
2017-06-03 13:18 ` [PATCH 20/25] xfs: xfs_trans_alloc_empty Christoph Hellwig
2017-06-03 13:18 ` [PATCH 21/25] xfs: avoid mount-time deadlock in CoW extent recovery Christoph Hellwig
2017-06-03 13:18 ` [PATCH 22/25] xfs: fix unaligned access in xfs_btree_visit_blocks Christoph Hellwig
2017-06-03 13:18 ` [PATCH 23/25] xfs: fix off-by-one on max nr_pages in xfs_find_get_desired_pgoff() Christoph Hellwig
2017-06-03 13:18 ` [PATCH 24/25] xfs: Fix missed holes in SEEK_HOLE implementation Christoph Hellwig
2017-06-03 13:18 ` [PATCH 25/25] xfs: Fix off-by-in in loop termination in xfs_find_get_desired_pgoff() Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170603131836.26661-10-hch@lst.de \
--to=hch@lst.de \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).