[patch 2/2] staging: lustre: validate size in ll_setxattr()

[patch 2/2] staging: lustre: validate size in ll_setxattr()

[Dan Carpenter]

If size is smaller than the lov_user_md struct then we are reading
beyond the end of the buffer.  I guess this is an information leak or it
could cause an Oops if the memory is not mapped.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
This was discovered through a code audit.  I'm not terribly familiar
with this code and I haven't tested it.  Please review it carefully.

diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
index 252a619..75abb97 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -223,6 +223,9 @@ int ll_setxattr(struct dentry *dentry, const char *name,
 	CDEBUG(D_VFSTRACE, "VFS Op:inode=%lu/%u(%p), xattr %s\n",
 	       inode->i_ino, inode->i_generation, inode, name);
 
+	if (size != 0 && size < sizeof(struct lov_user_md))
+		return -EINVAL;
+
 	ll_stats_ops_tally(ll_i2sbi(inode), LPROC_LL_SETXATTR, 1);
 
 	if ((strncmp(name, XATTR_TRUSTED_PREFIX,

Re: [patch 2/2] staging: lustre: validate size in ll_setxattr()

[Dan Carpenter]

On Wed, Oct 22, 2014 at 02:27:08PM +0400, Andrew Perepechko wrote:
> Hi Dan!
> 
> You probably meant putting that check after the followring if-statement,
> since generic extended attributes can have size 1, 2, 3, ...
> 

Ok.

> In that case, size = 0 seems to be the wrong value size for an lov param
> as well.

I don't know about this.  The code is very clear that size = 0 is
acceptable inside the if statement.  Oleg?

regards,
dan carpenter

Re: [patch 2/2] staging: lustre: validate size in ll_setxattr()

[Drokin, Oleg]

Hello!

On Oct 22, 2014, at 6:32 AM, Dan Carpenter wrote:
>> In that case, size = 0 seems to be the wrong value size for an lov param
>> as well.
> I don't know about this.  The code is very clear that size = 0 is
> acceptable inside the if statement.  Oleg?

I am not sure what if statement do you mean?
If it's the "if ((strncmp(name, XATTR_TRUSTED_PREFIX," one then size of 0
does seem to be incorrect:

                struct lov_user_md *lump = (struct lov_user_md *)value; 
// (I hope this is not a user pointer?)
…
                if (lump != NULL && lump->lmm_stripe_offset = 0)
                        lump->lmm_stripe_offset = -1;
// So, if lump is 0, we are already accessing past allowed range
…
                        int lum_size = (lump->lmm_magic = LOV_USER_MAGIC_V1) ?
and again…

Bye,
    Oleg

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2/2] staging: lustre: validate size in ll_setxattr()

[Dan Carpenter]

On Wed, Oct 22, 2014 at 01:53:15PM +0000, Drokin, Oleg wrote:
> Hello!
> 
> On Oct 22, 2014, at 6:32 AM, Dan Carpenter wrote:
> >> In that case, size = 0 seems to be the wrong value size for an lov param
> >> as well.
> > I don't know about this.  The code is very clear that size = 0 is
> > acceptable inside the if statement.  Oleg?
> 
> I am not sure what if statement do you mean?
> If it's the "if ((strncmp(name, XATTR_TRUSTED_PREFIX," one then size of 0
> does seem to be incorrect:
> 
>                 struct lov_user_md *lump = (struct lov_user_md *)value; 
> // (I hope this is not a user pointer?)

It's not.

> …
>                 if (lump != NULL && lump->lmm_stripe_offset = 0)
>                         lump->lmm_stripe_offset = -1;
> // So, if lump is 0, we are already accessing past allowed range

If size is zero then lump is NULL and the existing code is very careful
to test for that and avoid NULL dereferences.  I think that Andrew is
saying at it doesn't make sense for lump to be NULL.

Anyway, let me send a v2 which fixes the bug and leaves lump = NULL as
is.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html