lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a8f16e2b0705092341w14204283q9ddc225db73a5001@mail.gmail.com>
Date:	Thu, 10 May 2007 10:41:36 +0400
From:	"Dan Kruchinin" <dubalom@...il.com>
To:	"Randy Dunlap" <rdunlap@...otime.net>,
	linux-kernel@...r.kernel.org, linux-usb-devel@...t.sourceforge.net
Subject: Re: [linux-usb-devel] [PATCH -mm] drivers/usb/core/config.c: kzalloc(0, ..)

On 5/8/07, Randy Dunlap <rdunlap@...otime.net> wrote:
> On Tue, 8 May 2007 11:57:07 -0400 (EDT) Alan Stern wrote:
>
> > On Tue, 8 May 2007, Greg KH wrote:
> >
> > > >  The problem was in drivers/usb/core/config.c in function
> > > >  usb_parse_interface:
> > > >  ---
> > > >  num_ep = num_ep_orig = alt->desc.bNumEndpoints;
> > > >  ...
> > > >  len = sizeof(struct usb_host_endpoint) * num_ep;
> > > >  alt->endpoint = kzalloc(len, GFP_KERNEL);
> > > >  ---
> > > >
> > > >  num_ep can be 0, as it was in my case, so following patch makes this
> > > >  situation more obvious
> > > >  and clear.
> >
> > How about instead just doing:
> >
> > +     num_ep = max(num_ep, 1);
> >       len = sizeof(struct usb_host_endpoint) * num_ep;
> >
> > Also, wasn't it true at one point that it was legal to call kmalloc() with
> > a length of 0?  ISTR seeing somewhere that it's true for regular malloc().
>
> kmalloc(0) was legal with CONFIG_SLAB=y.  However, there is now
> something called SLUB, which just returned an error when size == 0.

SLUB works correctly with kmalloc(0) too, but it calls
WARN_ON_ONCE(size == 0);
in include/linux/slub_def.h: kmalloc_index.

btw: as I know when kmalloc(0) both slub and slab allocate the
smallest possible size. Can this size be smaller than sizeof(struct
usb_host_endpoint)? If it is, may it be a problem?

thanks.

Dan Kruchinin.

> It has recently been modified to mirror the SLAB behavior but also
> do a stack dump so that "bad" callers can be fixed.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ