xfs
[Top] [All Lists]

Re: [PATCH] Fix possible memory corruption in xfs_readlink

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] Fix possible memory corruption in xfs_readlink
From: Alex Elder <aelder@xxxxxxx>
Date: Wed, 2 Nov 2011 15:22:35 -0500
Cc: Ben Hutchings <ben@xxxxxxxxxxxxxxx>, Carlos Maiolino <cmaiolino@xxxxxxxxxx>, <xfs@xxxxxxxxxxx>
In-reply-to: <20111102194507.GA14429@xxxxxxxxxxxxx>
References: <1320156842.30281.28.camel@deadeye> <1320256339.3145.30.camel@doink> <20111102194507.GA14429@xxxxxxxxxxxxx>
Reply-to: <aelder@xxxxxxx>
On Wed, 2011-11-02 at 15:45 -0400, Christoph Hellwig wrote:
> We should validate that the value isn't negative in xfs_iformat_*,
> although we currently don't do that.  It already verified that it
> fits into the XFS_DFORK_DSIZE, which should take care of fitting
> into 32-bits.  Adding another explicit check probably won't hurt,
> given that XFS_DFORK_DSIZE is calculated dynamically based on the
> fork offset.
> 

That's true, but there are other places where it gets
updated, yet not defensively validated.  For example,
in xfs_dir2_shrink_inode(), if:
    fsbno > (INT64_MAX >> mp->m_sb.sb_blocklog)
then the (signed) di_size field would be assigned
a value that exceeded its max representable value,
producing unreliable (implementation-defined) results.
That may well be an impossible situation, but it's
not obvious without really looking at the code.

It's a bit of a can of worms, which is why I suggested
just testing for this (unlikely) condition in
xfs_readlink() for now.

                                        -Alex

<Prev in Thread] Current Thread [Next in Thread>