linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch] vfs: check for integer overflows in posix_acl_alloc()
@ 2013-06-24 16:27 Dan Carpenter
  2013-06-24 16:43 ` Dan Carpenter
  2013-06-24 21:37 ` Dave Chinner
  0 siblings, 2 replies; 4+ messages in thread
From: Dan Carpenter @ 2013-06-24 16:27 UTC (permalink / raw)
  To: Alexander Viro; +Cc: linux-fsdevel, linux-kernel

We've seen cases where people passed negative numbers to
posix_acl_alloc() and we fixed the caller.  For example 093019cf1b "xfs:
fix acl count validation in xfs_acl_from_disk()".  But there are other
places which might be affected like ext4_acl_from_disk() which checks
for negative but doesn't check an upper limit.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index cea4623..cd7fd2f 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -46,7 +46,12 @@ posix_acl_alloc(int count, gfp_t flags)
 {
 	const size_t size = sizeof(struct posix_acl) +
 	                    count * sizeof(struct posix_acl_entry);
-	struct posix_acl *acl = kmalloc(size, flags);
+	struct posix_acl *acl;
+
+	if (count < 0 || count > (SIZE_MAX - sizeof(struct posix_acl) /
+					sizeof(struct posix_acl_entry)))
+		return NULL;
+	acl = kmalloc(size, flags);
 	if (acl)
 		posix_acl_init(acl, count);
 	return acl;

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [patch] vfs: check for integer overflows in posix_acl_alloc()
  2013-06-24 16:27 [patch] vfs: check for integer overflows in posix_acl_alloc() Dan Carpenter
@ 2013-06-24 16:43 ` Dan Carpenter
  2013-06-24 21:37 ` Dave Chinner
  1 sibling, 0 replies; 4+ messages in thread
From: Dan Carpenter @ 2013-06-24 16:43 UTC (permalink / raw)
  To: Alexander Viro; +Cc: linux-fsdevel, linux-kernel

On Mon, Jun 24, 2013 at 07:27:19PM +0300, Dan Carpenter wrote:
> We've seen cases where people passed negative numbers to
> posix_acl_alloc() and we fixed the caller.  For example 093019cf1b "xfs:
> fix acl count validation in xfs_acl_from_disk()".  But there are other
> places which might be affected like ext4_acl_from_disk() which checks
> for negative but doesn't check an upper limit.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/fs/posix_acl.c b/fs/posix_acl.c
> index cea4623..cd7fd2f 100644
> --- a/fs/posix_acl.c
> +++ b/fs/posix_acl.c
> @@ -46,7 +46,12 @@ posix_acl_alloc(int count, gfp_t flags)
>  {
>  	const size_t size = sizeof(struct posix_acl) +
>  	                    count * sizeof(struct posix_acl_entry);
> -	struct posix_acl *acl = kmalloc(size, flags);
> +	struct posix_acl *acl;
> +
> +	if (count < 0 || count > (SIZE_MAX - sizeof(struct posix_acl) /
> +					sizeof(struct posix_acl_entry)))

Gar.  I completely screwed that up.  Please ignore this.  I will
send a better patch in a couple days.  I am sorry.

regards,
dan carpenter

> +		return NULL;
> +	acl = kmalloc(size, flags);
>  	if (acl)
>  		posix_acl_init(acl, count);
>  	return acl;

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] vfs: check for integer overflows in posix_acl_alloc()
  2013-06-24 16:27 [patch] vfs: check for integer overflows in posix_acl_alloc() Dan Carpenter
  2013-06-24 16:43 ` Dan Carpenter
@ 2013-06-24 21:37 ` Dave Chinner
  2013-06-25 13:32   ` Dan Carpenter
  1 sibling, 1 reply; 4+ messages in thread
From: Dave Chinner @ 2013-06-24 21:37 UTC (permalink / raw)
  To: Dan Carpenter, g; +Cc: Alexander Viro, linux-fsdevel, linux-kernel

On Mon, Jun 24, 2013 at 07:27:19PM +0300, Dan Carpenter wrote:
> We've seen cases where people passed negative numbers to
> posix_acl_alloc() and we fixed the caller.  For example 093019cf1b "xfs:
> fix acl count validation in xfs_acl_from_disk()".

Yeah, we failed to detect an on-disk corruption correctly....

> But there are other
> places which might be affected like ext4_acl_from_disk() which checks
> for negative but doesn't check an upper limit.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/fs/posix_acl.c b/fs/posix_acl.c
> index cea4623..cd7fd2f 100644
> --- a/fs/posix_acl.c
> +++ b/fs/posix_acl.c
> @@ -46,7 +46,12 @@ posix_acl_alloc(int count, gfp_t flags)
>  {
>  	const size_t size = sizeof(struct posix_acl) +
>  	                    count * sizeof(struct posix_acl_entry);
> -	struct posix_acl *acl = kmalloc(size, flags);
> +	struct posix_acl *acl;
> +
> +	if (count < 0 || count > (SIZE_MAX - sizeof(struct posix_acl) /
> +					sizeof(struct posix_acl_entry)))
> +		return NULL;

That's not going to solve your problems, because ACLs are limied by
filesystem on-disk formats, not SIZE_MAX.  The number of valid ACLs
is capped by the fact they are stored in xattrs on most (all?)
filesystems, and so are limited to fitting into the maximum
attribute data length which is 64k.

IOWs, the valid ACL limit is per-filesystem, and needs to be checked
in the filesystem code as something that is beyond the range of what
the on-disk format of the filesystem can handle is a corruption
event and needs to be treated as a corruption, not a ENOMEM error..

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] vfs: check for integer overflows in posix_acl_alloc()
  2013-06-24 21:37 ` Dave Chinner
@ 2013-06-25 13:32   ` Dan Carpenter
  0 siblings, 0 replies; 4+ messages in thread
From: Dan Carpenter @ 2013-06-25 13:32 UTC (permalink / raw)
  To: Dave Chinner; +Cc: g, Alexander Viro, linux-fsdevel, linux-kernel

Yeah.  You're right.  When I look at it more closely the ext4
example is capped ext4_get_acl().  Sorry for the noise.

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-06-25 13:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-24 16:27 [patch] vfs: check for integer overflows in posix_acl_alloc() Dan Carpenter
2013-06-24 16:43 ` Dan Carpenter
2013-06-24 21:37 ` Dave Chinner
2013-06-25 13:32   ` Dan Carpenter

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).