netdev - Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170206134621.GD3038@localhost>
Date:   Mon, 6 Feb 2017 14:46:21 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Petko Manolov <petkan@...leusys.com>
Cc:     Greg KH <greg@...ah.com>, Ben Hutchings <ben@...adent.org.uk>,
        netdev@...r.kernel.org, linux-usb@...r.kernel.org,
        Lisandro Damián Nicanor Pérez Meyer 
        <lisandro@...ian.org>
Subject: Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

On Mon, Feb 06, 2017 at 02:32:23PM +0100, Johan Hovold wrote:
> On Mon, Feb 06, 2017 at 02:21:24PM +0100, Johan Hovold wrote:
> > On Mon, Feb 06, 2017 at 02:51:09PM +0200, Petko Manolov wrote:
> > > On 17-02-06 09:28:22, Greg KH wrote:
> > > > On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:
> > 
> > > > > Random thought: isn't it better to add the alloc/free code in 
> > > > > usb_control_msg() and avoid code duplication all over the driver space?
> > > > 
> > > > A very long time ago we considered it, but realized that the majority of 
> > > > drivers already had the memory dynamically allocated, so we just went with 
> > > > this.  Perhaps we could revisit that if it turns out we were wrong, and would 
> > > > simplify things.
> > > 
> > > A quick glance at usb_control_msg() users (looked only at .../net/usb and 
> > > .../usb/serial) shows that most of them have the buffer allocated in stack.  
> > 
> > That's simply not true at all for usb-serial. If you find an instance
> > were a stack allocated buffer is used for DMA that hasn't yet been
> > fixed in USB serial, then please point it out so we can fix it up (I
> > doubt you'll find one, though).
> 
> Heh, I just found one myself (in ark3116) that I'll fix up. Please let
> me know if you find any more.

False alarm, the ark3116 driver is fine too.

Johan