linux-kernel - Re: [PATCH] net: usb: rtl8150: don't incorrectly assign random MAC addresses

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:   Sat, 10 Oct 2020 11:16:45 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Anant Thazhemadam <anant.thazhemadam@...il.com>
Cc:     linux-kernel-mentees@...ts.linuxfoundation.org,
        Petko Manolov <petkan@...leusys.com>,
        "David S. Miller" <davem@...emloft.net>, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: usb: rtl8150: don't incorrectly assign random MAC
 addresses

On Sat, 10 Oct 2020 23:34:51 +0530 Anant Thazhemadam wrote:
> On 10/10/20 10:29 pm, Jakub Kicinski wrote:
> > On Sat, 10 Oct 2020 12:14:59 +0530 Anant Thazhemadam wrote:  
> >> get_registers() directly returns the return value of
> >> usb_control_msg_recv() - 0 if successful, and negative error number 
> >> otherwise.  
> > Are you expecting Greg to take this as a part of some USB subsystem
> > changes? I don't see usb_control_msg_recv() in my tree, and the
> > semantics of usb_control_msg() are not what you described.  
> 
> No, I'm not. usb_control_msg_recv() is an API that was recently
> introduced, and get_registers() in rtl8150.c was also modified to
> use it in order to prevent partial reads.
> 
> By your tree, I assume you mean
>     https://git.kernel.org/pub/scm/linux/kernel/git/kuba/linux.git/
> (it was the only one I could find).
> 
> I don't see the commit that this patch is supposed to fix in your
> tree either... :/
> 
> Nonetheless, this commit fixes an issue that was applied to the
> networking tree, and has made its way into linux-next as well, if
> I'm not mistaken.

I mean the networking tree, what's the commit ID in linux-next?

Your fixes tag points to f45a4248ea4c, but looks like the code was
quite correct at that point.