[Linux-kernel-mentees,v2] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

Commit Message

Anant Thazhemadam Oct. 1, 2020, 7:32 a.m. UTC

When get_registers() fails (which happens when usb_control_msg() fails)
in set_ethernet_addr(), the uninitialized value of node_id gets copied
as the address.

Checking for the return values appropriately, and handling the case
wherein set_ethernet_addr() fails like this, helps in avoiding the
mac address being incorrectly set in this manner.

Reported-by: [e-mail]
Tested-by: [e-mail]
Signed-off-by: Anant Thazhemadam <[e-mail]>
Acked-by: Petko Manolov <[e-mail]>
---
Changes in v2:
	* Modified condition checking get_registers()'s return value to 
		ret == sizeof(node_id)
	  for stricter checking in compliance with the new usb_control_msg_recv()
	  API
	* Added Acked-by: Petko Manolov

Since Petko didn't explicitly mention an email-id in his Ack, I put the
email-id present in the MAINTAINERS file. I hope that's not an issue.


 drivers/net/usb/rtl8150.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

Comments

David Miller Oct. 2, 2020, 2:15 a.m. UTC | #1

From: Anant Thazhemadam <[e-mail]>
Date: Thu,  1 Oct 2020 13:02:20 +0530

> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.
> 
> Checking for the return values appropriately, and handling the case
> wherein set_ethernet_addr() fails like this, helps in avoiding the
> mac address being incorrectly set in this manner.
> 
> Reported-by: [e-mail]
> Tested-by: [e-mail]
> Signed-off-by: Anant Thazhemadam <[e-mail]>
> Acked-by: Petko Manolov <[e-mail]>

First, please remove "Linux-kernel-mentees" from the Subject line.

All patch submitters should have their work judged equally, whoever
they are.  So this Subject text gives no extra information, and it
simply makes scanning Subject lines in one's mailer more difficult.

Second, when a MAC address fails to probe a random MAC address should
be selected.  We have helpers for this.  This way an interface still
comes up and is usable, even in the event of a failed MAC address
probe.

Anant Thazhemadam Oct. 2, 2020, 11:34 a.m. UTC | #2

On 02/10/20 7:45 am, David Miller wrote:
> From: Anant Thazhemadam <[e-mail]>
> Date: Thu,  1 Oct 2020 13:02:20 +0530
>
>> When get_registers() fails (which happens when usb_control_msg() fails)
>> in set_ethernet_addr(), the uninitialized value of node_id gets copied
>> as the address.
>>
>> Checking for the return values appropriately, and handling the case
>> wherein set_ethernet_addr() fails like this, helps in avoiding the
>> mac address being incorrectly set in this manner.
>>
>> Reported-by: [e-mail]
>> Tested-by: [e-mail]
>> Signed-off-by: Anant Thazhemadam <[e-mail]>
>> Acked-by: Petko Manolov <[e-mail]>
> First, please remove "Linux-kernel-mentees" from the Subject line.
>
> All patch submitters should have their work judged equally, whoever
> they are.  So this Subject text gives no extra information, and it
> simply makes scanning Subject lines in one's mailer more difficult.
I will keep that in mind for all future submissions. Thank you.

> Second, when a MAC address fails to probe a random MAC address should
> be selected.  We have helpers for this.  This way an interface still
> comes up and is usable, even in the event of a failed MAC address
> probe.

Okay... I see.
But this patch is about ensuring that an uninitialized variable's
value (whatever that may be) is not set as the ethernet address
blindly (without any form of checking if get_registers() worked
as expected, or not). And I didn't think uninitialized values being
set as MAC address was considered a good outcome (after all, it
seemed to have triggered a bug), especially when it could have
been avoided by introducing a simple check that doesn't break
anything.
However, if I was mistaken, and if that is something that we can live
with after all, then I don't really see the understand the purpose of
similar checks being made (in all the many places that the return
value of get_registers() (or a similar function gets checked) in the first
place at all.

In all honesty, this confused me a little more than it provided clarity,
and I hope someone could help me shift that balance back to clarity
again.

Thank you for your time.

Thanks,
Anant

Greg KH Oct. 2, 2020, 11:54 a.m. UTC | #3

On Fri, Oct 02, 2020 at 05:04:13PM +0530, Anant Thazhemadam wrote:
> 
> On 02/10/20 7:45 am, David Miller wrote:
> > From: Anant Thazhemadam <[e-mail]>
> > Date: Thu,  1 Oct 2020 13:02:20 +0530
> >
> >> When get_registers() fails (which happens when usb_control_msg() fails)
> >> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> >> as the address.
> >>
> >> Checking for the return values appropriately, and handling the case
> >> wherein set_ethernet_addr() fails like this, helps in avoiding the
> >> mac address being incorrectly set in this manner.
> >>
> >> Reported-by: [e-mail]
> >> Tested-by: [e-mail]
> >> Signed-off-by: Anant Thazhemadam <[e-mail]>
> >> Acked-by: Petko Manolov <[e-mail]>
> > First, please remove "Linux-kernel-mentees" from the Subject line.
> >
> > All patch submitters should have their work judged equally, whoever
> > they are.  So this Subject text gives no extra information, and it
> > simply makes scanning Subject lines in one's mailer more difficult.
> I will keep that in mind for all future submissions. Thank you.
> 
> > Second, when a MAC address fails to probe a random MAC address should
> > be selected.  We have helpers for this.  This way an interface still
> > comes up and is usable, even in the event of a failed MAC address
> > probe.
> 
> Okay... I see.
> But this patch is about ensuring that an uninitialized variable's
> value (whatever that may be) is not set as the ethernet address
> blindly (without any form of checking if get_registers() worked
> as expected, or not). And I didn't think uninitialized values being
> set as MAC address was considered a good outcome (after all, it
> seemed to have triggered a bug), especially when it could have
> been avoided by introducing a simple check that doesn't break
> anything.

If the read from the device for the MAC address fails, don't abort the
whole probe process and make the device not work at all, call the
networking core to assign a random MAC address.

> However, if I was mistaken, and if that is something that we can live
> with after all, then I don't really see the understand the purpose of
> similar checks being made (in all the many places that the return
> value of get_registers() (or a similar function gets checked) in the first
> place at all.

Different values and registers determine what should be done with an
error.  It's all relative.

For this type of error, we should gracefully recover and keep on going.
For others, maybe we just ignore the issue, or log it, or something
else, it all depends.

hope this helps,

greg k-h

Anant Thazhemadam Oct. 2, 2020, 12:05 p.m. UTC | #4

On 02-10-2020 17:24, Greg KH wrote:
> On Fri, Oct 02, 2020 at 05:04:13PM +0530, Anant Thazhemadam wrote:
>> On 02/10/20 7:45 am, David Miller wrote:
>>> From: Anant Thazhemadam <[e-mail]>
>>> Date: Thu,  1 Oct 2020 13:02:20 +0530
>>>
>>>> When get_registers() fails (which happens when usb_control_msg() fails)
>>>> in set_ethernet_addr(), the uninitialized value of node_id gets copied
>>>> as the address.
>>>>
>>>> Checking for the return values appropriately, and handling the case
>>>> wherein set_ethernet_addr() fails like this, helps in avoiding the
>>>> mac address being incorrectly set in this manner.
>>>>
>>>> Reported-by: [e-mail]
>>>> Tested-by: [e-mail]
>>>> Signed-off-by: Anant Thazhemadam <[e-mail]>
>>>> Acked-by: Petko Manolov <[e-mail]>
>>> First, please remove "Linux-kernel-mentees" from the Subject line.
>>>
>>> All patch submitters should have their work judged equally, whoever
>>> they are.  So this Subject text gives no extra information, and it
>>> simply makes scanning Subject lines in one's mailer more difficult.
>> I will keep that in mind for all future submissions. Thank you.
>>
>>> Second, when a MAC address fails to probe a random MAC address should
>>> be selected.  We have helpers for this.  This way an interface still
>>> comes up and is usable, even in the event of a failed MAC address
>>> probe.
>> Okay... I see.
>> But this patch is about ensuring that an uninitialized variable's
>> value (whatever that may be) is not set as the ethernet address
>> blindly (without any form of checking if get_registers() worked
>> as expected, or not). And I didn't think uninitialized values being
>> set as MAC address was considered a good outcome (after all, it
>> seemed to have triggered a bug), especially when it could have
>> been avoided by introducing a simple check that doesn't break
>> anything.
> If the read from the device for the MAC address fails, don't abort the
> whole probe process and make the device not work at all, call the
> networking core to assign a random MAC address.
>
>> However, if I was mistaken, and if that is something that we can live
>> with after all, then I don't really see the understand the purpose of
>> similar checks being made (in all the many places that the return
>> value of get_registers() (or a similar function gets checked) in the first
>> place at all.
> Different values and registers determine what should be done with an
> error.  It's all relative.
>
> For this type of error, we should gracefully recover and keep on going.
> For others, maybe we just ignore the issue, or log it, or something
> else, it all depends.
>
> hope this helps,
>
> greg k-h
Yes, this clears things up for me. I'll see to it that this gets done in a v3.

Thanks,
Anant

Petko Manolov Oct. 2, 2020, 2:29 p.m. UTC | #5

On 20-10-02 17:35:25, Anant Thazhemadam wrote:
> 
> Yes, this clears things up for me. I'll see to it that this gets done in a v3.

If set_ethernet_addr() fail, don't return error, but use eth_hw_addr_random() 
instead to set random MAC address and continue with the probing.

You can take a look here:
https://lore.kernel.org/netdev/[e-mail]/


cheers,
Petko

David Miller Oct. 2, 2020, 10:38 p.m. UTC | #6

From: Anant Thazhemadam <[e-mail]>
Date: Fri, 2 Oct 2020 17:04:13 +0530

> But this patch is about ensuring that an uninitialized variable's
> value (whatever that may be) is not set as the ethernet address
> blindly (without any form of checking if get_registers() worked
> as expected, or not).

Right, and if you are going to check for errors then you have to
handle the error properly.

And the proper way to handle this error is to set a random ethernet
address on the device.

Anant Thazhemadam Oct. 3, 2020, 5:51 a.m. UTC | #7

On 02-10-2020 19:59, Petko Manolov wrote:
> On 20-10-02 17:35:25, Anant Thazhemadam wrote:
>> Yes, this clears things up for me. I'll see to it that this gets done in a v3.
> If set_ethernet_addr() fail, don't return error, but use eth_hw_addr_random() 
> instead to set random MAC address and continue with the probing.
>
> You can take a look here:
> https://lore.kernel.org/netdev/[e-mail]/
>
>
> cheers,
> Petko
Thank you for this reference. :)

Thanks,
Anant

Anant Thazhemadam Oct. 3, 2020, 5:54 a.m. UTC | #8

On 03-10-2020 04:08, David Miller wrote:
> From: Anant Thazhemadam <[e-mail]>
> Date: Fri, 2 Oct 2020 17:04:13 +0530
>
>> But this patch is about ensuring that an uninitialized variable's
>> value (whatever that may be) is not set as the ethernet address
>> blindly (without any form of checking if get_registers() worked
>> as expected, or not).
> Right, and if you are going to check for errors then you have to
> handle the error properly.
>
> And the proper way to handle this error is to set a random ethernet
> address on the device.

Yes, I've understood that now.
I've prepared and tested a v3 accordingly, and will have it sent in soon enough.
Thank you so much for this!  :)

Thanks,
Anant

Joe Perches Oct. 3, 2020, 7:38 p.m. UTC | #9

On Thu, 2020-10-01 at 13:02 +0530, Anant Thazhemadam wrote:
> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.

unrelated trivia:

> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
[]
> @@ -274,12 +274,17 @@ static int write_mii_word(rtl8150_t * dev, u8 phy, __u8 indx, u16 reg)
>  		return 1;
>  }
>  
> -static inline void set_ethernet_addr(rtl8150_t * dev)
> +static bool set_ethernet_addr(rtl8150_t *dev)
>  {
>  	u8 node_id[6];

This might be better as:

	u8 node_id[ETH_ALEN];

> +	int ret;
>  
> -	get_registers(dev, IDR, sizeof(node_id), node_id);
> -	memcpy(dev->netdev->dev_addr, node_id, sizeof(node_id));
> +	ret = get_registers(dev, IDR, sizeof(node_id), node_id);
> +	if (ret == sizeof(node_id)) {
> +		memcpy(dev->netdev->dev_addr, node_id, sizeof(node_id));

and
		ether_addr_copy(dev->netdev->dev_addr, node_id);

Anant Thazhemadam Oct. 3, 2020, 8:58 p.m. UTC | #10

On 04/10/20 1:08 am, Joe Perches wrote:
> On Thu, 2020-10-01 at 13:02 +0530, Anant Thazhemadam wrote:
>> When get_registers() fails (which happens when usb_control_msg() fails)
>> in set_ethernet_addr(), the uninitialized value of node_id gets copied
>> as the address.
> unrelated trivia:
>
>> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> []
>> @@ -274,12 +274,17 @@ static int write_mii_word(rtl8150_t * dev, u8 phy, __u8 indx, u16 reg)
>>  		return 1;
>>  }
>>  
>> -static inline void set_ethernet_addr(rtl8150_t * dev)
>> +static bool set_ethernet_addr(rtl8150_t *dev)
>>  {
>>  	u8 node_id[6];
> This might be better as:
>
> 	u8 node_id[ETH_ALEN];
>
>> +	int ret;
>>  
>> -	get_registers(dev, IDR, sizeof(node_id), node_id);
>> -	memcpy(dev->netdev->dev_addr, node_id, sizeof(node_id));
>> +	ret = get_registers(dev, IDR, sizeof(node_id), node_id);
>> +	if (ret == sizeof(node_id)) {
>> +		memcpy(dev->netdev->dev_addr, node_id, sizeof(node_id));
> and
> 		ether_addr_copy(dev->netdev->dev_addr, node_id);
>
>
I will include this change as well, in the v3.
Thank you for pointing that out.

Thanks,
Anant

Patch

diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 733f120c852b..e542a9ab2ff8 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -150,7 +150,7 @@  static const char driver_name [] = "rtl8150";
 **	device related part of the code
 **
 */
-static int get_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
+static int get_registers(rtl8150_t *dev, u16 indx, u16 size, void *data)
 {
 	void *buf;
 	int ret;
@@ -274,12 +274,17 @@  static int write_mii_word(rtl8150_t * dev, u8 phy, __u8 indx, u16 reg)
 		return 1;
 }
 
-static inline void set_ethernet_addr(rtl8150_t * dev)
+static bool set_ethernet_addr(rtl8150_t *dev)
 {
 	u8 node_id[6];
+	int ret;
 
-	get_registers(dev, IDR, sizeof(node_id), node_id);
-	memcpy(dev->netdev->dev_addr, node_id, sizeof(node_id));
+	ret = get_registers(dev, IDR, sizeof(node_id), node_id);
+	if (ret == sizeof(node_id)) {
+		memcpy(dev->netdev->dev_addr, node_id, sizeof(node_id));
+		return true;
+	}
+	return false;
 }
 
 static int rtl8150_set_mac_address(struct net_device *netdev, void *p)
@@ -909,21 +914,24 @@  static int rtl8150_probe(struct usb_interface *intf,
 		goto out1;
 	}
 	fill_skb_pool(dev);
-	set_ethernet_addr(dev);
-
+	if (!set_ethernet_addr(dev)) {
+		dev_err(&intf->dev, "couldn't set the ethernet address for the device\n");
+		goto out2;
+	}
 	usb_set_intfdata(intf, dev);
 	SET_NETDEV_DEV(netdev, &intf->dev);
 	if (register_netdev(netdev) != 0) {
 		dev_err(&intf->dev, "couldn't register the device\n");
-		goto out2;
+		goto out3;
 	}
 
 	dev_info(&intf->dev, "%s: rtl8150 is detected\n", netdev->name);
 
 	return 0;
 
-out2:
+out3:
 	usb_set_intfdata(intf, NULL);
+out2:
 	free_skb_pool(dev);
 out1:
 	free_all_urbs(dev);