* [PATCH] xfs: don't perform lookups on zero-height btrees
@ 2016-08-19 20:30 Darrick J. Wong
2016-08-24 18:01 ` Brian Foster
2016-08-25 8:04 ` Christoph Hellwig
0 siblings, 2 replies; 4+ messages in thread
From: Darrick J. Wong @ 2016-08-19 20:30 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-xfs, xfs
If the caller passes in a cursor to a zero-height btree (which is
impossible), we never set block to anything but NULL, which causes the
later dereference of it to crash. Instead, just return -EFSCORRUPTED.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
fs/xfs/libxfs/xfs_btree.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c
index 64fd847..4bffea4 100644
--- a/fs/xfs/libxfs/xfs_btree.c
+++ b/fs/xfs/libxfs/xfs_btree.c
@@ -1814,6 +1814,10 @@ xfs_btree_lookup(
XFS_BTREE_STATS_INC(cur, lookup);
+ /* No such thing as a zero-level tree. */
+ if (cur->bc_nlevels == 0)
+ return -EFSCORRUPTED;
+
block = NULL;
keyno = 0;
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: don't perform lookups on zero-height btrees
2016-08-19 20:30 [PATCH] xfs: don't perform lookups on zero-height btrees Darrick J. Wong
@ 2016-08-24 18:01 ` Brian Foster
2016-08-24 20:39 ` Darrick J. Wong
2016-08-25 8:04 ` Christoph Hellwig
1 sibling, 1 reply; 4+ messages in thread
From: Brian Foster @ 2016-08-24 18:01 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs, xfs
On Fri, Aug 19, 2016 at 01:30:22PM -0700, Darrick J. Wong wrote:
> If the caller passes in a cursor to a zero-height btree (which is
> impossible), we never set block to anything but NULL, which causes the
> later dereference of it to crash. Instead, just return -EFSCORRUPTED.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
Did something actually cause this to happen?
Brian
> fs/xfs/libxfs/xfs_btree.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c
> index 64fd847..4bffea4 100644
> --- a/fs/xfs/libxfs/xfs_btree.c
> +++ b/fs/xfs/libxfs/xfs_btree.c
> @@ -1814,6 +1814,10 @@ xfs_btree_lookup(
>
> XFS_BTREE_STATS_INC(cur, lookup);
>
> + /* No such thing as a zero-level tree. */
> + if (cur->bc_nlevels == 0)
> + return -EFSCORRUPTED;
> +
> block = NULL;
> keyno = 0;
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: don't perform lookups on zero-height btrees
2016-08-24 18:01 ` Brian Foster
@ 2016-08-24 20:39 ` Darrick J. Wong
0 siblings, 0 replies; 4+ messages in thread
From: Darrick J. Wong @ 2016-08-24 20:39 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-xfs, xfs
On Wed, Aug 24, 2016 at 02:01:55PM -0400, Brian Foster wrote:
> On Fri, Aug 19, 2016 at 01:30:22PM -0700, Darrick J. Wong wrote:
> > If the caller passes in a cursor to a zero-height btree (which is
> > impossible), we never set block to anything but NULL, which causes the
> > later dereference of it to crash. Instead, just return -EFSCORRUPTED.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
>
> Did something actually cause this to happen?
Well, if you took a reflink xfs that was formatted before we added the
rmap/refcount btree block counters to the AGF and then tried to mount
it after will blow up like this, because the refcount_level field got
moved to somewhere that's zero in the old image.
Anyone being malicious with xfs_db can also do this to any other _level field.
(Yay automounting!)
--D
>
> Brian
>
> > fs/xfs/libxfs/xfs_btree.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c
> > index 64fd847..4bffea4 100644
> > --- a/fs/xfs/libxfs/xfs_btree.c
> > +++ b/fs/xfs/libxfs/xfs_btree.c
> > @@ -1814,6 +1814,10 @@ xfs_btree_lookup(
> >
> > XFS_BTREE_STATS_INC(cur, lookup);
> >
> > + /* No such thing as a zero-level tree. */
> > + if (cur->bc_nlevels == 0)
> > + return -EFSCORRUPTED;
> > +
> > block = NULL;
> > keyno = 0;
> >
> >
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: don't perform lookups on zero-height btrees
2016-08-19 20:30 [PATCH] xfs: don't perform lookups on zero-height btrees Darrick J. Wong
2016-08-24 18:01 ` Brian Foster
@ 2016-08-25 8:04 ` Christoph Hellwig
1 sibling, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2016-08-25 8:04 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs, xfs
On Fri, Aug 19, 2016 at 01:30:22PM -0700, Darrick J. Wong wrote:
> If the caller passes in a cursor to a zero-height btree (which is
> impossible), we never set block to anything but NULL, which causes the
> later dereference of it to crash. Instead, just return -EFSCORRUPTED.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
maybe also throw in an unlikely notation, though..
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-08-25 8:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-19 20:30 [PATCH] xfs: don't perform lookups on zero-height btrees Darrick J. Wong
2016-08-24 18:01 ` Brian Foster
2016-08-24 20:39 ` Darrick J. Wong
2016-08-25 8:04 ` Christoph Hellwig
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.