linux-kernel - RE: [PATCH] usb: gadget: aspeed: fix buffer overflow

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]

Date:   Fri, 28 Oct 2022 09:04:52 +0000
From:   Neal Liu <neal_liu@...eedtech.com>
To:     Lei Yu <yulei.sh@...edance.com>
CC:     Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        Henry Tian <tianxiaofeng@...edance.com>,
        Jakob Koschel <jakobkoschel@...il.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ryan Chen <ryan_chen@...eedtech.com>
Subject: RE: [PATCH] usb: gadget: aspeed: fix buffer overflow

> > Thanks for your feedback.
> > I tried to reproduce it on my side, and it cannot be reproduce it.
> > Here are my test sequences:
> > 1. emulate one of the vhub port to usb ethernet through Linux gadget
> > (ncm)
> 
> We are using rndis instead of ncm.
> 
> > 2. connect BMC vhub to Host
> > 3. BMC & Host can ping each other (both usb eth dev default mtu is
> > 1500) 4. Set BMC mtu to 1000 (Host OS cannot set usb eth dev mtu to
> > 2000, it's maxmtu is 1500)
> 
> Not sure if it's related, but in my case (USB rndis, Debian 10 OS) it should be
> able to set MTU to 2000.

Using rndis is able to set MTU to 2000, and the issue can be reproduced.
Using ncm & ecm has no this issue because buffer length is more bigger than the received data length. (FYI)
Thanks.

Reviewed-by: Neal Liu <neal_liu@...eedtech.com>

> 
> > 5. ping BMC with `s -1500` argument from Host OS 6. BMC kernel no oops
> >
> > I dumped the `req` related members in ast_vhub_epn_handle_ack() to see if
> whether the received data length exceeds the buffer length.
> > In my case `req.length` is 16384 bytes, so it never exceeds it in this case.
> > I'm wondering what's the value of `req.length` in your test scenario? And
> how can I reproduce it?
> 
> The last 3 calls of ast_vhub_epn_handle_ack():
> 
> ast_vhub_epn_handle_ack：req->last_desc=-1
> req.actual=1024,req.length=1578,ep->ep.maxpacket=512
> ast_vhub_epn_handle_ack：req->last_desc=-1
> req.actual=1536,req.length=1578,ep->ep.maxpacket=512
> ast_vhub_epn_handle_ack：req->last_desc=1
> req.actual=1634,req.length=1578,ep->ep.maxpacket=512
> 
> We can see the last packet 1634 exceeds the req.legnth 1578, and that's when
> the buffer overflow occurs.