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>] [day] [month] [year] [list]
Date:	Tue, 19 Jan 2016 17:04:54 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Insu Yun <wuninsu@...il.com>
cc:	gregkh@...uxfoundation.org, <stefan.koch10@...il.com>,
	Kris Borer <kborer@...il.com>, <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Taesoo Kim <taesoo@...ech.edu>,
	Yeongjin Jang <yeongjin.jang@...ech.edu>,
	"Yun, Insu" <insu@...ech.edu>, Changwoo Min <changwoo@...ech.edu>
Subject: Re: [PATCH] usb: fix potential integer overflow in usb_sg_init

On Tue, 19 Jan 2016, Insu Yun wrote:

> On Tue, Jan 19, 2016 at 9:57 AM, Alan Stern <stern@...land.harvard.edu>
> wrote:
> 
> > On Mon, 18 Jan 2016, Insu Yun wrote:
> >
> > > On Mon, Jan 18, 2016 at 1:32 PM, Alan Stern <stern@...land.harvard.edu>
> > > wrote:
> > >
> > > > On Mon, 18 Jan 2016, Insu Yun wrote:
> > > >
> > > > > If nents value is sufficient large, e.g 0x40000000,
> > > > > then it can overflow size in kmalloc and heap overflow happesns.
> > > > > Therefore nents value needs to be checked to prevent overflow.
> > > >
> > > > I don't see why.  You seem to be assuming that failure with -EINVAL is
> > > > better than failure with a heap overflow.  I disagree; a heap overflow
> > > > provides more debugging information to help locate the reason for the
> > > > underlying problem.
> > > >
> > >
> > > I agree that heap overflow gives more information than -EINVAL.
> > > However, I think -EINVAL already gives sufficient information for
> > debugging.
> >
> > Actually it doesn't.  -EINVAL return codes occur all over the place.
> > It's not easy to tell exactly what went wrong when one of them pops up.
> >
> > > And I thin crash is bad, so returning -EINVAL seems better.
> >
> > A better solution in this case would be to avoid overflows by changing
> > the kmalloc call to kmalloc_array, instead of duplicating the code.
> >
> 
> But if we use kmalloc_array, then it cannot be distinguished between memory
> pressure and overflow case.
> It will be failed with -ENOMEM.
> I think it is worse in terms of debugging information that you mentioned.

In practice, it doesn't matter whether the failure is caused by memory 
pressure or numerical overflow.  In both cases the underlying reason is 
the same: too many scatterlist entries.

Besides, this is all highly theoretical.  Do you have any evidence that 
people are encountering cases where nents is larger than (say) 20?

If you want to prevent overflows and crashes, then fine -- use 
kmalloc_array.  Other than that, I don't see any need to change the 
code.

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ