[PATCH] xfs: fix possible overflow in xfs_ioc_trim()

[PATCH] xfs: fix possible overflow in xfs_ioc_trim()

[Lukas Czerner]

In xfs_ioc_trim it is possible that start+len might overflow. Fix it by
decrementing the len so that start+len equals to the file system size in
the worst case.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
---
 fs/xfs/xfs_discard.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fs/xfs/xfs_discard.c b/fs/xfs/xfs_discard.c
index 244e797..0fab107 100644
--- a/fs/xfs/xfs_discard.c
+++ b/fs/xfs/xfs_discard.c
@@ -146,6 +146,7 @@ xfs_ioc_trim(
 	unsigned int		granularity = q->limits.discard_granularity;
 	struct fstrim_range	range;
 	xfs_fsblock_t		start, len, minlen;
+	xfs_fsblock_t		max_blks =  XFS_MAX_DBLOCKS(&(mp->m_sb));
 	xfs_agnumber_t		start_agno, end_agno, agno;
 	__uint64_t		blocks_trimmed = 0;
 	int			error, last_error = 0;
@@ -171,7 +172,8 @@ xfs_ioc_trim(
 	start_agno = XFS_FSB_TO_AGNO(mp, start);
 	if (start_agno >= mp->m_sb.sb_agcount)
 		return -XFS_ERROR(EINVAL);
-
+	if (len > max_blks)
+		len = max_blks - start;
 	end_agno = XFS_FSB_TO_AGNO(mp, start + len);
 	if (end_agno >= mp->m_sb.sb_agcount)
 		end_agno = mp->m_sb.sb_agcount - 1;
-- 
1.7.4.4

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim()

[Christoph Hellwig]

On Mon, Sep 05, 2011 at 04:33:25PM +0200, Lukas Czerner wrote:
> In xfs_ioc_trim it is possible that start+len might overflow. Fix it by
> decrementing the len so that start+len equals to the file system size in
> the worst case.

The idea of the check looks reasonable, but I think it needs to be done
a bit different.  Was this caught by the new testcase you just sent?

> +	xfs_fsblock_t		max_blks =  XFS_MAX_DBLOCKS(&(mp->m_sb));

XFS_MAX_DBLOCKS is the maximum number of blocks that the given
geometry could support.  But the last AG could be shorter than the
others.  I think you really want to check against mp->m_sb.sb_dblocks.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim()

[Lukas Czerner]

On Tue, 6 Sep 2011, Christoph Hellwig wrote:

> On Mon, Sep 05, 2011 at 04:33:25PM +0200, Lukas Czerner wrote:
> > In xfs_ioc_trim it is possible that start+len might overflow. Fix it by
> > decrementing the len so that start+len equals to the file system size in
> > the worst case.
> 
> The idea of the check looks reasonable, but I think it needs to be done
> a bit different.  Was this caught by the new testcase you just sent?

Actually I have found the problem in other file systems too (ext4 and
btrfs) while doing test similar to the one sent recently to xfstests.
Then I fixed the problems, and then I have created the xfstests test for
it so it is clear what the correct behaviour should look like. So yes,
the testcase would have caught the problem.

> 
> > +	xfs_fsblock_t		max_blks =  XFS_MAX_DBLOCKS(&(mp->m_sb));
> 
> XFS_MAX_DBLOCKS is the maximum number of blocks that the given
> geometry could support.  But the last AG could be shorter than the
> others.  I think you really want to check against mp->m_sb.sb_dblocks.
> 

ah, ok, I'll change that. Thanks!

-Lukas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim()

[Chandra Seetharaman]

On Mon, 2011-09-05 at 16:33 +0200, Lukas Czerner wrote:
> In xfs_ioc_trim it is possible that start+len might overflow. Fix it by
> decrementing the len so that start+len equals to the file system size in
> the worst case.
> 
> Signed-off-by: Lukas Czerner <lczerner@redhat.com>
> ---
>  fs/xfs/xfs_discard.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/xfs/xfs_discard.c b/fs/xfs/xfs_discard.c
> index 244e797..0fab107 100644
> --- a/fs/xfs/xfs_discard.c
> +++ b/fs/xfs/xfs_discard.c
> @@ -146,6 +146,7 @@ xfs_ioc_trim(
>  	unsigned int		granularity = q->limits.discard_granularity;
>  	struct fstrim_range	range;
>  	xfs_fsblock_t		start, len, minlen;
> +	xfs_fsblock_t		max_blks =  XFS_MAX_DBLOCKS(&(mp->m_sb));
>  	xfs_agnumber_t		start_agno, end_agno, agno;
>  	__uint64_t		blocks_trimmed = 0;
>  	int			error, last_error = 0;
> @@ -171,7 +172,8 @@ xfs_ioc_trim(
>  	start_agno = XFS_FSB_TO_AGNO(mp, start);
>  	if (start_agno >= mp->m_sb.sb_agcount)
>  		return -XFS_ERROR(EINVAL);
> -
> +	if (len > max_blks)

just wondering....

shouldn't this be ((start + len) > max_blks) ?

> +		len = max_blks - start;
>  	end_agno = XFS_FSB_TO_AGNO(mp, start + len);
>  	if (end_agno >= mp->m_sb.sb_agcount)
>  		end_agno = mp->m_sb.sb_agcount - 1;


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim()

[Lukas Czerner]

On Wed, 7 Sep 2011, Chandra Seetharaman wrote:

> On Mon, 2011-09-05 at 16:33 +0200, Lukas Czerner wrote:
> > In xfs_ioc_trim it is possible that start+len might overflow. Fix it by
> > decrementing the len so that start+len equals to the file system size in
> > the worst case.
> > 
> > Signed-off-by: Lukas Czerner <lczerner@redhat.com>
> > ---
> >  fs/xfs/xfs_discard.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_discard.c b/fs/xfs/xfs_discard.c
> > index 244e797..0fab107 100644
> > --- a/fs/xfs/xfs_discard.c
> > +++ b/fs/xfs/xfs_discard.c
> > @@ -146,6 +146,7 @@ xfs_ioc_trim(
> >  	unsigned int		granularity = q->limits.discard_granularity;
> >  	struct fstrim_range	range;
> >  	xfs_fsblock_t		start, len, minlen;
> > +	xfs_fsblock_t		max_blks =  XFS_MAX_DBLOCKS(&(mp->m_sb));
> >  	xfs_agnumber_t		start_agno, end_agno, agno;
> >  	__uint64_t		blocks_trimmed = 0;
> >  	int			error, last_error = 0;
> > @@ -171,7 +172,8 @@ xfs_ioc_trim(
> >  	start_agno = XFS_FSB_TO_AGNO(mp, start);
> >  	if (start_agno >= mp->m_sb.sb_agcount)
> >  		return -XFS_ERROR(EINVAL);
> > -
> > +	if (len > max_blks)
> 
> just wondering....
> 
> shouldn't this be ((start + len) > max_blks) ?

Yes the patch is not correct. See

http://www.spinics.net/lists/xfs/msg06897.html

> 
> > +		len = max_blks - start;
> >  	end_agno = XFS_FSB_TO_AGNO(mp, start + len);
> >  	if (end_agno >= mp->m_sb.sb_agcount)
> >  		end_agno = mp->m_sb.sb_agcount - 1;
> 
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs