linux-kernel - Re: [PATCH] usb: fix potential integer overflow in usb_sg

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]

Message-ID: <Pine.LNX.4.44L0.1601191655270.1312-100000@iolanthe.rowland.org>
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