linux-kernel - Re: Toby MPCI - L201 cellular modem http hang after random MAC address assignment

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]

Date:   Fri, 27 Mar 2020 13:56:17 -0700
From:   Bobby Jones <rjones@...eworks.com>
To:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Allison Randal <allison@...utok.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Steve Winslow <swinslow@...il.com>,
        Bjørn Mork <bjorn@...k.no>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        linux-usb@...r.kernel.org, modemmanager-devel@...ts.freedesktop.org
Subject: Re: Toby MPCI - L201 cellular modem http hang after random MAC
 address assignment

On Mon, Mar 23, 2020 at 10:21 AM Bobby Jones <rjones@...eworks.com> wrote:
>
> Hello net-dev,
>
> I'm diagnosing a problem with the Toby MPCI-L201 cellular modem where
> http operations hang. This is reproducible on the most recent kernel
> by turning on the rndis_host driver and executing a wget or similar
> http command. I found I was able to still ping but not transfer any
> data. After bisecting I've found that commit
> a5a18bdf7453d505783e40e47ebb84bfdd35f93b introduces this hang.
>
> For reference the patch contents are:
>
> >     rndis_host: Set valid random MAC on buggy devices
> >
> >     Some devices of the same type all export the same, random MAC address. This
> >     behavior has been seen on the ZTE MF910, MF823 and MF831, and there are
> >     probably more devices out there. Fix this by generating a valid random MAC
> >     address if we read a random MAC from device.
> >
> >     Also, changed the memcpy() to ether_addr_copy(), as pointed out by
> >     checkpatch.
> >
> >     Suggested-by: Bjørn Mork <bjorn@...k.no>
> >     Signed-off-by: Kristian Evensen <kristian.evensen@...il.com>
> >     Signed-off-by: David S. Miller <davem@...emloft.net>
> > diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
> > index 524a47a28120..4f4f71b2966b 100644
> > --- a/drivers/net/usb/rndis_host.c
> > +++ b/drivers/net/usb/rndis_host.c
> > @@ -428,7 +428,11 @@ generic_rndis_bind(struct usbnet *dev, struct usb_interface *intf, int flags)
> >                 dev_err(&intf->dev, "rndis get ethaddr, %d\n", retval);
> >                 goto halt_fail_and_release;
> >         }
> > -       memcpy(net->dev_addr, bp, ETH_ALEN);
> > +
> > +       if (bp[0] & 0x02)
> > +               eth_hw_addr_random(net);
> > +       else
> > +               ether_addr_copy(net->dev_addr, bp);
> >
> >         /* set a nonzero filter to enable data transfers */
> >         memset(u.set, 0, sizeof *u.set);
>
> I know that there is some internal routing done by the modem firmware,
> and I'm assuming that overwriting the MAC address breaks said routing.
> Can anyone suggest what a proper fix would be?
>
> Thanks,
> Bobby

Adding some individuals and lists in hopes for feedback