linux-kernel - Re: [PATCH AUTOSEL 5.8 18/24] net: usb: rtl8150: set random MAC address when set_ethernet

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] [day] [month] [year] [list]

Date:   Wed, 14 Oct 2020 10:04:01 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Petko Manolov <petkan@...leusys.com>
Cc:     Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org,
        Anant Thazhemadam <anant.thazhemadam@...il.com>,
        syzbot+abbc768b560c84d92fd3@...kaller.appspotmail.com,
        "David S . Miller" <davem@...emloft.net>,
        linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.8 18/24] net: usb: rtl8150: set random MAC
 address when set_ethernet_addr() fails

On Tue, Oct 13, 2020 at 12:01:06AM +0300, Petko Manolov wrote:
>On 20-10-12 12:11:18, Joe Perches wrote:
>> On Mon, 2020-10-12 at 15:02 -0400, Sasha Levin wrote:
>> > From: Anant Thazhemadam <anant.thazhemadam@...il.com>
>> >
>> > [ Upstream commit f45a4248ea4cc13ed50618ff066849f9587226b2 ]
>> >
>> > When get_registers() fails in set_ethernet_addr(),the uninitialized
>> > value of node_id gets copied over as the address.
>> > So, check the return value of get_registers().
>> >
>> > If get_registers() executed successfully (i.e., it returns
>> > sizeof(node_id)), copy over the MAC address using ether_addr_copy()
>> > (instead of using memcpy()).
>> >
>> > Else, if get_registers() failed instead, a randomly generated MAC
>> > address is set as the MAC address instead.
>>
>> This autosel is premature.
>>
>> This patch always sets a random MAC.
>> See the follow on patch: https://lkml.org/lkml/2020/10/11/131
>> To my knowledge, this follow-ob has yet to be applied:
>
>ACK, the follow-on patch has got the correct semantics.

I'll hold off on this patch until the follow-on is merged, thanks!

-- 
Thanks,
Sasha