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 15:41:53 +0800
From:   Lei Yu <yulei.sh@...edance.com>
To:     Neal Liu <neal_liu@...eedtech.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

On Fri, Oct 28, 2022 at 2:59 PM Neal Liu <neal_liu@...eedtech.com> wrote:
>
> 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.

> 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.

Powered by blists - more mailing lists