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: <YXkCVLJrQC7ig31t@hovoldconsulting.com>
Date:   Wed, 27 Oct 2021 09:40:04 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Kalle Valo <kvalo@...eaurora.org>,
        Amitkumar Karwar <amitkarwar@...il.com>,
        Ganapathi Bhat <ganapathi017@...il.com>,
        Sharvari Harisangam <sharvari.harisangam@....com>,
        Xinming Hu <huxinming820@...il.com>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Amitkumar Karwar <akarwar@...vell.com>
Subject: Re: [PATCH 3/3] mwifiex: fix division by zero in fw download path

On Tue, Oct 26, 2021 at 10:35:37AM -0700, Brian Norris wrote:
> On Tue, Oct 26, 2021 at 2:53 AM Johan Hovold <johan@...nel.org> wrote:
> >
> > Add the missing endpoint max-packet sanity check to probe() to avoid
> > division by zero in mwifiex_write_data_sync() in case a malicious device
> > has broken descriptors (or when doing descriptor fuzz testing).
> >
> > Note that USB core will reject URBs submitted for endpoints with zero
> > wMaxPacketSize but that drivers doing packet-size calculations still
> > need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
> > endpoint descriptors with maxpacket=0")).
> >
> > Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset")
> > Cc: stable@...r.kernel.org      # 3.5
> > Cc: Amitkumar Karwar <akarwar@...vell.com>
> > Signed-off-by: Johan Hovold <johan@...nel.org>
> > ---
> 
> Seems like you're missing a changelog and a version number, since
> you've already sent previous versions of this patch.

Seems like you're confusing me with someone else.
 
> >  drivers/net/wireless/marvell/mwifiex/usb.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
> > index 426e39d4ccf0..2826654907d9 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/usb.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/usb.c
> > @@ -502,6 +502,9 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
> >                         atomic_set(&card->tx_cmd_urb_pending, 0);
> >                         card->bulk_out_maxpktsize =
> >                                         le16_to_cpu(epd->wMaxPacketSize);
> > +                       /* Reject broken descriptors. */
> > +                       if (card->bulk_out_maxpktsize == 0)
> > +                               return -ENODEV;
> 
> If we're really talking about malicious devices, I'm still not 100%
> sure this is sufficient -- what if the device doesn't advertise the
> right endpoints? Might we get through the surrounding loop without
> ever even reaching this code? Seems like the right thing to do would
> be to pull the validation outside the loop.

But you're right about this. The driver looks up its resources but still
proceeds if they're not there (and will eventually try to submit URBs
for the default pipe).

I'll send a v2.

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ