From: Dan Carpenter <dan.carpenter@oracle.com>
To: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Cc: Steve French <sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>,
linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [patch] cifs: integer overflow in parse_dacl()
Date: Wed, 11 Jan 2012 12:41:32 +0000 [thread overview]
Message-ID: <20120111124132.GO3644@mwanda> (raw)
In-Reply-To: <20120111072029.672dfdca-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
On Wed, Jan 11, 2012 at 07:20:29AM -0500, Jeff Layton wrote:
> On Wed, 11 Jan 2012 10:46:27 +0300
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> > On 32 bit systems num_aces * sizeof(struct cifs_ace *) could overflow
> > leading to a smaller ppace buffer than we expected.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
> > index 72ddf23..c1b2544 100644
> > --- a/fs/cifs/cifsacl.c
> > +++ b/fs/cifs/cifsacl.c
> > @@ -909,6 +909,8 @@ static void parse_dacl(struct cifs_acl *pdacl, char *end_of_acl,
> > umode_t group_mask = S_IRWXG;
> > umode_t other_mask = S_IRWXU | S_IRWXG | S_IRWXO;
> >
> > + if (num_aces > ULONG_MAX / sizeof(struct cifs_ace *))
> > + return;
> > ppace = kmalloc(num_aces * sizeof(struct cifs_ace *),
> > GFP_KERNEL);
> > if (!ppace) {
>
>
> Looks plausible. This function could use some work. I'm not sure why
> num_aces is signed here too...
>
> The first arg to kmalloc is a size_t. Does that boil down to an unsigned
> long on all arches?
People have been submitting a lot of patches recently based on that
assumption. It matches the check in kcalloc() as well. According
to include/asm-generic/posix_types.h:
/*
* Most 32 bit architectures use "unsigned int" size_t,
* and all 64 bit architectures use "unsigned long" size_t.
*/
It would be better to user a lower limit, but I don't know the code
well enough to say if which one is good that won't break things...
A high number can trigger a kmalloc() failure and that puts annoying
spam in the dmesg.
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Cc: Steve French <sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>,
linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [patch] cifs: integer overflow in parse_dacl()
Date: Wed, 11 Jan 2012 15:41:32 +0300 [thread overview]
Message-ID: <20120111124132.GO3644@mwanda> (raw)
In-Reply-To: <20120111072029.672dfdca-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]
On Wed, Jan 11, 2012 at 07:20:29AM -0500, Jeff Layton wrote:
> On Wed, 11 Jan 2012 10:46:27 +0300
> Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>
> > On 32 bit systems num_aces * sizeof(struct cifs_ace *) could overflow
> > leading to a smaller ppace buffer than we expected.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> >
> > diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
> > index 72ddf23..c1b2544 100644
> > --- a/fs/cifs/cifsacl.c
> > +++ b/fs/cifs/cifsacl.c
> > @@ -909,6 +909,8 @@ static void parse_dacl(struct cifs_acl *pdacl, char *end_of_acl,
> > umode_t group_mask = S_IRWXG;
> > umode_t other_mask = S_IRWXU | S_IRWXG | S_IRWXO;
> >
> > + if (num_aces > ULONG_MAX / sizeof(struct cifs_ace *))
> > + return;
> > ppace = kmalloc(num_aces * sizeof(struct cifs_ace *),
> > GFP_KERNEL);
> > if (!ppace) {
>
>
> Looks plausible. This function could use some work. I'm not sure why
> num_aces is signed here too...
>
> The first arg to kmalloc is a size_t. Does that boil down to an unsigned
> long on all arches?
People have been submitting a lot of patches recently based on that
assumption. It matches the check in kcalloc() as well. According
to include/asm-generic/posix_types.h:
/*
* Most 32 bit architectures use "unsigned int" size_t,
* and all 64 bit architectures use "unsigned long" size_t.
*/
It would be better to user a lower limit, but I don't know the code
well enough to say if which one is good that won't break things...
A high number can trigger a kmalloc() failure and that puts annoying
spam in the dmesg.
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-01-11 12:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 7:46 [patch] cifs: integer overflow in parse_dacl() Dan Carpenter
2012-01-11 7:46 ` Dan Carpenter
[not found] ` <20120111074627.GA4519-mgFCXtclrQlZLf2FXnZxJA@public.gmane.org>
2012-01-11 12:20 ` Jeff Layton
2012-01-11 12:20 ` Jeff Layton
[not found] ` <20120111072029.672dfdca-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2012-01-11 12:41 ` Dan Carpenter [this message]
2012-01-11 12:41 ` Dan Carpenter
2012-01-11 13:33 ` Jeff Layton
2012-01-11 13:33 ` Jeff Layton
2012-01-11 15:50 ` Shirish Pargaonkar
2012-01-11 15:50 ` Shirish Pargaonkar
[not found] ` <CADT32eLVwQT9V67BX8TkjVHDnQoYS7OqA_-xbnjY57ZXO3EfsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-11 17:24 ` Steve French
2012-01-11 17:24 ` Steve French
[not found] ` <CAH2r5muDQUL=0HcoFHH3QvP7C2pyy0=S9ESFBcm=qOYg3ESdxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-11 18:20 ` Jeff Layton
2012-01-11 18:20 ` Jeff Layton
[not found] ` <20120111132053.467e8cae-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2012-01-11 18:31 ` Steve French
2012-01-11 18:31 ` Steve French
[not found] ` <CAH2r5msciOkxvxTrQrN9mKKCiJvM_anmxU7sag_TGk92LoKEwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-12 7:06 ` Dan Carpenter
2012-01-12 7:06 ` Dan Carpenter
2012-01-12 19:17 ` Steve French
2012-01-12 19:17 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120111124132.GO3644@mwanda \
--to=dan.carpenter@oracle.com \
--cc=jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
--cc=kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org \
--cc=sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.