All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anant Thazhemadam <anant.thazhemadam@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-kernel-mentees@lists.linuxfoundation.org,
	syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com,
	Petko Manolov <petkan@nucleusys.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-usb@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Linux-kernel-mentees][PATCH] rtl8150: set memory to all 0xFFs on failed register reads
Date: Wed, 16 Sep 2020 19:10:55 +0530	[thread overview]
Message-ID: <dfdb48b8-5cd9-2b19-11cc-b17f45904e0f@gmail.com> (raw)
In-Reply-To: <20200916062227.GD142621@kroah.com>


On 16/09/20 11:52 am, Greg KH wrote:
> On Wed, Sep 16, 2020 at 10:35:40AM +0530, Anant Thazhemadam wrote:
>> get_registers() copies whatever memory is written by the
>> usb_control_msg() call even if the underlying urb call ends up failing.
>>
>> If get_registers() fails, or ends up reading 0 bytes, meaningless and 
>> junk register values would end up being copied over (and eventually read 
>> by the driver), and since most of the callers of get_registers() don't 
>> check the return values of get_registers() either, this would go unnoticed.
>>
>> It might be a better idea to try and mirror the PCI master abort
>> termination and set memory to 0xFFs instead in such cases.
> It would be better to use this new api call instead of
> usb_control_msg():
> 	https://lore.kernel.org/r/20200914153756.3412156-1-gregkh@linuxfoundation.org
>
> How about porting this patch to run on top of that series instead?  That
> should make this logic much simpler.
This looks viable to me. I'll be sure to try this out.
>> Fixes: https://syzkaller.appspot.com/bug?extid=abbc768b560c84d92fd3
>> Reported-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com
>> Tested-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com
>> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
>> ---
>>  drivers/net/usb/rtl8150.c | 9 +++++++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
>> index 733f120c852b..04fca7bfcbcb 100644
>> --- a/drivers/net/usb/rtl8150.c
>> +++ b/drivers/net/usb/rtl8150.c
>> @@ -162,8 +162,13 @@ static int get_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
>>  	ret = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
>>  			      RTL8150_REQ_GET_REGS, RTL8150_REQT_READ,
>>  			      indx, 0, buf, size, 500);
>> -	if (ret > 0 && ret <= size)
>> +
>> +	if (ret < 0)
>> +		memset(data, 0xff, size);
>> +
>> +	else
>>  		memcpy(data, buf, ret);
>> +
>>  	kfree(buf);
>>  	return ret;
>>  }
>> @@ -276,7 +281,7 @@ static int write_mii_word(rtl8150_t * dev, u8 phy, __u8 indx, u16 reg)
>>  
>>  static inline void set_ethernet_addr(rtl8150_t * dev)
>>  {
>> -	u8 node_id[6];
>> +	u8 node_id[6] = {0};
> This should not be needed to be done.

Noted.

Thank you for your time.

Thanks,
Anant


WARNING: multiple messages have this Message-ID (diff)
From: Anant Thazhemadam <anant.thazhemadam@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Petko Manolov <petkan@nucleusys.com>,
	syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com,
	netdev@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Linux-kernel-mentees] [PATCH] rtl8150: set memory to all 0xFFs on failed register reads
Date: Wed, 16 Sep 2020 19:10:55 +0530	[thread overview]
Message-ID: <dfdb48b8-5cd9-2b19-11cc-b17f45904e0f@gmail.com> (raw)
In-Reply-To: <20200916062227.GD142621@kroah.com>


On 16/09/20 11:52 am, Greg KH wrote:
> On Wed, Sep 16, 2020 at 10:35:40AM +0530, Anant Thazhemadam wrote:
>> get_registers() copies whatever memory is written by the
>> usb_control_msg() call even if the underlying urb call ends up failing.
>>
>> If get_registers() fails, or ends up reading 0 bytes, meaningless and 
>> junk register values would end up being copied over (and eventually read 
>> by the driver), and since most of the callers of get_registers() don't 
>> check the return values of get_registers() either, this would go unnoticed.
>>
>> It might be a better idea to try and mirror the PCI master abort
>> termination and set memory to 0xFFs instead in such cases.
> It would be better to use this new api call instead of
> usb_control_msg():
> 	https://lore.kernel.org/r/20200914153756.3412156-1-gregkh@linuxfoundation.org
>
> How about porting this patch to run on top of that series instead?  That
> should make this logic much simpler.
This looks viable to me. I'll be sure to try this out.
>> Fixes: https://syzkaller.appspot.com/bug?extid=abbc768b560c84d92fd3
>> Reported-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com
>> Tested-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com
>> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
>> ---
>>  drivers/net/usb/rtl8150.c | 9 +++++++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
>> index 733f120c852b..04fca7bfcbcb 100644
>> --- a/drivers/net/usb/rtl8150.c
>> +++ b/drivers/net/usb/rtl8150.c
>> @@ -162,8 +162,13 @@ static int get_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
>>  	ret = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
>>  			      RTL8150_REQ_GET_REGS, RTL8150_REQT_READ,
>>  			      indx, 0, buf, size, 500);
>> -	if (ret > 0 && ret <= size)
>> +
>> +	if (ret < 0)
>> +		memset(data, 0xff, size);
>> +
>> +	else
>>  		memcpy(data, buf, ret);
>> +
>>  	kfree(buf);
>>  	return ret;
>>  }
>> @@ -276,7 +281,7 @@ static int write_mii_word(rtl8150_t * dev, u8 phy, __u8 indx, u16 reg)
>>  
>>  static inline void set_ethernet_addr(rtl8150_t * dev)
>>  {
>> -	u8 node_id[6];
>> +	u8 node_id[6] = {0};
> This should not be needed to be done.

Noted.

Thank you for your time.

Thanks,
Anant

_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  parent reply	other threads:[~2020-09-16 20:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16  5:05 [Linux-kernel-mentees][PATCH] rtl8150: set memory to all 0xFFs on failed register reads Anant Thazhemadam
2020-09-16  5:05 ` [Linux-kernel-mentees] [PATCH] " Anant Thazhemadam
2020-09-16  6:19 ` [Linux-kernel-mentees][PATCH] " Petko Manolov
2020-09-16  6:19   ` [Linux-kernel-mentees] [PATCH] " Petko Manolov
2020-09-16 13:38   ` [Linux-kernel-mentees][PATCH] " Anant Thazhemadam
2020-09-16 13:38     ` [Linux-kernel-mentees] [PATCH] " Anant Thazhemadam
2020-09-16  6:22 ` [Linux-kernel-mentees][PATCH] " Greg KH
2020-09-16  6:22   ` [Linux-kernel-mentees] [PATCH] " Greg KH
2020-09-16  6:39   ` [Linux-kernel-mentees][PATCH] " Petko Manolov
2020-09-16  6:39     ` [Linux-kernel-mentees] [PATCH] " Petko Manolov
2020-09-16 13:40   ` Anant Thazhemadam [this message]
2020-09-16 13:40     ` Anant Thazhemadam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfdb48b8-5cd9-2b19-11cc-b17f45904e0f@gmail.com \
    --to=anant.thazhemadam@gmail.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=petkan@nucleusys.com \
    --cc=syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.