staging: rtl8712: fix KMSAN: uninit-value in r871xu_drv_init

PATCH Superseded Wang Cheng 2 participants 9 messages May 6, 2022 – May 10, 2022 Staging

lore

Share & tools

lore

Wang Cheng

author

2022-05-06 11:59 UTC #0 lore raw

v3 cover staging: rtl8712: fix KMSAN: uninit-value in r871xu_drv_init

Changelog v2->v3:
- Add error handler in r8712_usbctrl_vendorreq().

v2: https://lore.kernel.org/lkml/[email protected]/

Wang Cheng (3):
staging: rtl8712: fix uninit-value in usb_read8() and friends
staging: rtl8712: fix uninit-value in r871xu_drv_init()
staging: rtl8712: add error handler in r8712_usbctrl_vendorreq()

 drivers/staging/rtl8712/usb_intf.c      |  6 +++---
 drivers/staging/rtl8712/usb_ops.c       | 27 ++++++++++++++++---------
 drivers/staging/rtl8712/usb_ops_linux.c | 21 ++++++++++++-------
 3 files changed, 35 insertions(+), 19 deletions(-)

Signature · 1 line

2.33.1

Wang Cheng

author

2022-05-06 11:59 UTC #1 lore raw

PATCH v3 1/3 staging: rtl8712: fix uninit-value in usb_read8() and friends

When r8712_usbctrl_vendorreq() returns negative, 'data' in usb_read{8,16,32} will not be initialized.

BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline]
BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725
 string_nocheck lib/vsprintf.c:643 [inline]
 string+0x4ec/0x6f0 lib/vsprintf.c:725
 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
 va_format lib/vsprintf.c:1704 [inline]
 pointer+0x18e6/0x1f70 lib/vsprintf.c:2443
 vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810
 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
 dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604
 dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615
 __dev_printk+0x3be/0x440 drivers/base/core.c:4627
 _dev_info+0x1ea/0x22f drivers/base/core.c:4673
 r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401
 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
 really_probe+0x6c7/0x1350 drivers/base/dd.c:621
 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
 driver_probe_device drivers/base/dd.c:782 [inline]
 __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
 __device_attach+0x593/0x8e0 drivers/base/dd.c:970
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
 device_add+0x1fff/0x26e0 drivers/base/core.c:3405
 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
 really_probe+0x6c7/0x1350 drivers/base/dd.c:621
 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
 driver_probe_device drivers/base/dd.c:782 [inline]
 __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
 __device_attach+0x593/0x8e0 drivers/base/dd.c:970
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
 device_add+0x1fff/0x26e0 drivers/base/core.c:3405
 usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566
 hub_port_connect drivers/usb/core/hub.c:5363 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5507 [inline]
 port_event drivers/usb/core/hub.c:5665 [inline]
 hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747
 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289
 worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436
 kthread+0x3c7/0x500 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30

Local variable data created at:

 usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33
 r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29

Reported-and-tested-by [email protected]

Signed-off-by Wang Cheng <[email protected]>

---
 drivers/staging/rtl8712/usb_ops.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

drivers/staging/rtl8712/usb_ops.c +18 -9

index e64845e6adf3..af9966d03979 100644
@@ -29,7 +29,8 @@ static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr)
 	u16 wvalue;
 	u16 index;
 	u16 len;
-	__le32 data;
+	int status;
+	__le32 data = 0;
 	struct intf_priv *intfpriv = intfhdl->pintfpriv;
 
 	request = 0x05;

@@ -37,8 +38,10 @@ static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr)
 	index = 0;
 	wvalue = (u16)(addr & 0x0000ffff);
 	len = 1;
-	r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index, &data, len,
-				requesttype);
+	status = r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index,
+					 &data, len, requesttype);
+	if (status < 0)
+		return 0;
 	return (u8)(le32_to_cpu(data) & 0x0ff);
 }

@@ -49,7 +52,8 @@ static u16 usb_read16(struct intf_hdl *intfhdl, u32 addr)
 	u16 wvalue;
 	u16 index;
 	u16 len;
-	__le32 data;
+	int status;
+	__le32 data = 0;
 	struct intf_priv *intfpriv = intfhdl->pintfpriv;
 
 	request = 0x05;

@@ -57,8 +61,10 @@ static u16 usb_read16(struct intf_hdl *intfhdl, u32 addr)
 	index = 0;
 	wvalue = (u16)(addr & 0x0000ffff);
 	len = 2;
-	r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index, &data, len,
-				requesttype);
+	status = r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index,
+					 &data, len, requesttype);
+	if (status < 0)
+		return 0;
 	return (u16)(le32_to_cpu(data) & 0xffff);
 }

@@ -69,7 +75,8 @@ static u32 usb_read32(struct intf_hdl *intfhdl, u32 addr)
 	u16 wvalue;
 	u16 index;
 	u16 len;
-	__le32 data;
+	int status;
+	__le32 data = 0;
 	struct intf_priv *intfpriv = intfhdl->pintfpriv;
 
 	request = 0x05;

@@ -77,8 +84,10 @@ static u32 usb_read32(struct intf_hdl *intfhdl, u32 addr)
 	index = 0;
 	wvalue = (u16)(addr & 0x0000ffff);
 	len = 4;
-	r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index, &data, len,
-				requesttype);
+	status = r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index,
+					 &data, len, requesttype);
+	if (status < 0)
+		return 0;
 	return le32_to_cpu(data);
 }

Signature · 1 line

2.33.1

Pavel Skripkin

2022-05-06 12:12 UTC #2 lore raw

Re: [PATCH v3 1/3] staging: rtl8712: fix uninit-value in usb_read8() and friends

Hi Wang,

Quoted 21 lines · Wang Cheng

Reported-and-tested-by [email protected]

Signed-off-by Wang Cheng <[email protected]>

---
  drivers/staging/rtl8712/usb_ops.c | 27 ++++++++++++++++++---------
  1 file changed, 18 insertions(+), 9 deletions(-)

drivers/staging/rtl8712/usb_ops.c +2 -1

index e64845e6adf3..af9966d03979 100644
@@ -29,7 +29,8 @@ static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr)
  	u16 wvalue;
  	u16 index;
  	u16 len;
-	__le32 data;
+	int status;
+	__le32 data = 0;
  	struct intf_priv *intfpriv = intfhdl->pintfpriv;
 
  	request = 0x05;

drivers/staging/rtl8712/usb_ops.c static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr) · line 44

Quoted 9 lines

drivers/staging/rtl8712/usb_ops.c +4 -2

@@ -37,8 +38,10 @@ static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr)
  	index = 0;
  	wvalue = (u16)(addr & 0x0000ffff);
  	len = 1;
-	r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index, &data, len,
-				requesttype);
+	status = r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index,
+					 &data, len, requesttype);
+	if (status < 0)
+		return 0;

Wait, but what about partial reads? I see that r8712_usbctrl_vendorreq() uses usb_control_msg() which can read less data than was requested.

So here you are just hiding these error by zeroing data

drivers/staging/rtl8712/usb_ops.c static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr) · line 47

Quoted 3 lines

drivers/staging/rtl8712/usb_ops.c +0 -0
  	return (u8)(le32_to_cpu(data) & 0x0ff);
  }
 

And as i said in previous email: caller can't see an error.

Imagine caller waits for some register to become 0. Caller sees that usb_read8() returned 0. Is it an error? Is register really become 0?

Generic read API prototype looks like following:

int read_something(struct my_cool_dev *dev, void *data, size_t size);

and it returns 0 on success and -errno on failure and data returned via passed pointer. So, if API returned an error caller should not touch @data, since likely it's uninitialized

With regards,
Pavel Skripkin

Wang Cheng

author

2022-05-10 03:34 UTC #3 lore raw

Re: [PATCH v3 1/3] staging: rtl8712: fix uninit-value in usb_read8() and friends

Quoted 47 lines · Pavel Skripkin

Hi Wang,
Quoted 20 lines · Wang Cheng
Reported-and-tested-by [email protected]
Signed-off-by Wang Cheng <[email protected]>
---
  drivers/staging/rtl8712/usb_ops.c | 27 ++++++++++++++++++---------
  1 file changed, 18 insertions(+), 9 deletions(-)
drivers/staging/rtl8712/usb_ops.c +2 -1
index e64845e6adf3..af9966d03979 100644
@@ -29,7 +29,8 @@ static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr)
  	u16 wvalue;
  	u16 index;
  	u16 len;
-	__le32 data;
+	int status;
+	__le32 data = 0;
  	struct intf_priv *intfpriv = intfhdl->pintfpriv;
  	request = 0x05;
drivers/staging/rtl8712/usb_ops.c static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr) · line 44
Quoted 9 lines
drivers/staging/rtl8712/usb_ops.c +4 -2
@@ -37,8 +38,10 @@ static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr)
  	index = 0;
  	wvalue = (u16)(addr & 0x0000ffff);
  	len = 1;
-	r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index, &data, len,
-				requesttype);
+	status = r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index,
+					 &data, len, requesttype);
+	if (status < 0)
+		return 0;
Wait, but what about partial reads? I see that r8712_usbctrl_vendorreq() uses usb_control_msg() which can read less data than was requested.
So here you are just hiding these error by zeroing data
drivers/staging/rtl8712/usb_ops.c static u8 usb_read8(struct intf_hdl *intfhdl, u32 addr) · line 46
Quoted 2 lines
drivers/staging/rtl8712/usb_ops.c +0 -0
  	return (u8)(le32_to_cpu(data) & 0x0ff);
  }
And as i said in previous email: caller can't see an error.
Imagine caller waits for some register to become 0. Caller sees that usb_read8() returned 0. Is it an error? Is register really become 0?

Quoted 7 lines

Generic read API prototype looks like following:
int read_something(struct my_cool_dev *dev, void *data, size_t size);
and it returns 0 on success and -errno on failure and data returned via passed pointer. So, if API returned an error caller should not touch @data, since likely it's uninitialized

Thank you for your remind, sorry I didnt understand your previous reply about "register and 0" that you explain very clearly above. I am thinking about it standing on that the return type of usb_read8() is u8.

thanks,
- w

Wang Cheng

author

2022-05-06 12:00 UTC #4 lore raw

PATCH v3 2/3 staging: rtl8712: fix uninit-value in r871xu_drv_init()

In reply to Wang Cheng

When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized.

BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
 really_probe+0x653/0x14b0 drivers/base/dd.c:596
 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
 driver_probe_device drivers/base/dd.c:782 [inline]
 __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
 __device_attach+0x593/0x8e0 drivers/base/dd.c:970
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
 device_add+0x1fff/0x26e0 drivers/base/core.c:3405
 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
 really_probe+0x653/0x14b0 drivers/base/dd.c:596
 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
 driver_probe_device drivers/base/dd.c:782 [inline]
 __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
 __device_attach+0x593/0x8e0 drivers/base/dd.c:970
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
 device_add+0x1fff/0x26e0 drivers/base/core.c:3405
 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566
 hub_port_connect drivers/usb/core/hub.c:5358 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5502 [inline]
 port_event drivers/usb/core/hub.c:5660 [inline]
 hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742
 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307
 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454
 kthread+0x3c7/0x500 kernel/kthread.c:377
 ret_from_fork+0x1f/0x30

Local variable mac created at:

 r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394
 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396

Reported-and-tested-by [email protected]

Signed-off-by Wang Cheng <[email protected]>

---
 drivers/staging/rtl8712/usb_intf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/staging/rtl8712/usb_intf.c +3 -3

index ee4c61f85a07..50dcd3ecb685 100644
@@ -538,13 +538,13 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
 		} else {
 			AutoloadFail = false;
 		}
-		if (((mac[0] == 0xff) && (mac[1] == 0xff) &&
+		if ((!AutoloadFail) ||
+		    ((mac[0] == 0xff) && (mac[1] == 0xff) &&
 		     (mac[2] == 0xff) && (mac[3] == 0xff) &&
 		     (mac[4] == 0xff) && (mac[5] == 0xff)) ||
 		    ((mac[0] == 0x00) && (mac[1] == 0x00) &&
 		     (mac[2] == 0x00) && (mac[3] == 0x00) &&
-		     (mac[4] == 0x00) && (mac[5] == 0x00)) ||
-		     (!AutoloadFail)) {
+		     (mac[4] == 0x00) && (mac[5] == 0x00))) {
 			mac[0] = 0x00;
 			mac[1] = 0xe0;
 			mac[2] = 0x4c;

Signature · 1 line

2.33.1

Pavel Skripkin

2022-05-06 12:27 UTC #5 lore raw

Re: [PATCH v3 2/3] staging: rtl8712: fix uninit-value in r871xu_drv_init()

Hi Wang,

Quoted 17 lines · Wang Cheng

Reported-and-tested-by [email protected]

Signed-off-by Wang Cheng <[email protected]>

---
  drivers/staging/rtl8712/usb_intf.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

drivers/staging/rtl8712/usb_intf.c +2 -1

index ee4c61f85a07..50dcd3ecb685 100644
@@ -538,13 +538,13 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
  		} else {
  			AutoloadFail = false;
  		}
-		if (((mac[0] == 0xff) && (mac[1] == 0xff) &&
+		if ((!AutoloadFail) ||
+		    ((mac[0] == 0xff) && (mac[1] == 0xff) &&

drivers/staging/rtl8712/usb_intf.c static int r871xu_drv_init(struct usb_interface *pusb_intf, · line 550

Quoted 10 lines

drivers/staging/rtl8712/usb_intf.c +1 -2

  		     (mac[2] == 0xff) && (mac[3] == 0xff) &&
  		     (mac[4] == 0xff) && (mac[5] == 0xff)) ||
  		    ((mac[0] == 0x00) && (mac[1] == 0x00) &&
  		     (mac[2] == 0x00) && (mac[3] == 0x00) &&
-		     (mac[4] == 0x00) && (mac[5] == 0x00)) ||
-		     (!AutoloadFail)) {
+		     (mac[4] == 0x00) && (mac[5] == 0x00))) {
  			mac[0] = 0x00;
  			mac[1] = 0xe0;
  			mac[2] = 0x4c;

Hmm,

the whole r871xu_drv_init() looks odd, but it's unrelated.

I see that this patch does not help with below kernel path

r871xu_drv_init()
if (tmpU1b & _EEPROM_EN) <- true [1]

	if (!r8712_initmac || !mac_pton(r8712_initmac, mac)) <- (*)
		if ((!AutoloadFail) ||	<- false, since [1] branch taken
			[code touches stack data]

(*) false because of r8712_initmac is equal to NULL

I saw, that syzbot said OK on your patch, but it's because you have just hided an error inside read API

With regards,
Pavel Skripkin

Pavel Skripkin

2022-05-06 12:35 UTC #6 lore raw

Re: [PATCH v3 2/3] staging: rtl8712: fix uninit-value in r871xu_drv_init()

Hi Pavel,

Quoted 37 lines · Pavel Skripkin

Hi Wang,
Quoted 17 lines · Wang Cheng
Reported-and-tested-by [email protected]
Signed-off-by Wang Cheng <[email protected]>
---
  drivers/staging/rtl8712/usb_intf.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
drivers/staging/rtl8712/usb_intf.c +2 -1
index ee4c61f85a07..50dcd3ecb685 100644
@@ -538,13 +538,13 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
  		} else {
  			AutoloadFail = false;
  		}
-		if (((mac[0] == 0xff) && (mac[1] == 0xff) &&
+		if ((!AutoloadFail) ||
+		    ((mac[0] == 0xff) && (mac[1] == 0xff) &&
drivers/staging/rtl8712/usb_intf.c static int r871xu_drv_init(struct usb_interface *pusb_intf, · line 550
Quoted 10 lines
drivers/staging/rtl8712/usb_intf.c +1 -2
  		     (mac[2] == 0xff) && (mac[3] == 0xff) &&
  		     (mac[4] == 0xff) && (mac[5] == 0xff)) ||
  		    ((mac[0] == 0x00) && (mac[1] == 0x00) &&
  		     (mac[2] == 0x00) && (mac[3] == 0x00) &&
-		     (mac[4] == 0x00) && (mac[5] == 0x00)) ||
-		     (!AutoloadFail)) {
+		     (mac[4] == 0x00) && (mac[5] == 0x00))) {
  			mac[0] = 0x00;
  			mac[1] = 0xe0;
  			mac[2] = 0x4c;
Hmm,
the whole r871xu_drv_init() looks odd, but it's unrelated.
I see that this patch does not help with below kernel path

Quoted 8 lines

r871xu_drv_init()

    if (tmpU1b & _EEPROM_EN) <- true [1]
	if (!r8712_initmac || !mac_pton(r8712_initmac, mac)) <- (*)
		if ((!AutoloadFail) ||	<- false, since [1] branch taken
			[code touches stack data]

(*) false because of r8712_initmac is equal to NULL

Oops, I am blind, ignore that one, please. The whole idea is wrong.

I need to go to sleep earlier today

sorry about that,

With regards,
Pavel Skripkin

Wang Cheng

author

2022-05-06 12:01 UTC #7 lore raw

PATCH v3 3/3 staging: rtl8712: add error handler in r8712_usbctrl_vendorreq()

In reply to Wang Cheng

When 'status' returned from usb_control_msg() is not equal to 'len', that usb_control_msg() is on partial failure, r8712_usbctrl_vendorreq() will treat partial reads as success.

Signed-off-by Wang Cheng <[email protected]>

---
 drivers/staging/rtl8712/usb_ops_linux.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

drivers/staging/rtl8712/usb_ops_linux.c +14 -7

index f984a5ab2c6f..b2181e1e2d38 100644
@@ -495,14 +495,21 @@ int r8712_usbctrl_vendorreq(struct intf_priv *pintfpriv, u8 request, u16 value,
 	}
 	status = usb_control_msg(udev, pipe, request, reqtype, value, index,
 				 pIo_buf, len, 500);
-	if (status > 0) {  /* Success this control transfer. */
-		if (requesttype == 0x01) {
-			/* For Control read transfer, we have to copy the read
-			 * data from pIo_buf to pdata.
-			 */
-			memcpy(pdata, pIo_buf,  status);
-		}
+	if (status < 0)
+		goto free;
+	if (status != len) {
+		status = -EREMOTEIO;
+		goto free;
+	}
+	/* Success this control transfer. */
+	if (requesttype == 0x01) {
+		/* For Control read transfer, we have to copy the read
+		 * data from pIo_buf to pdata.
+		 */
+		memcpy(pdata, pIo_buf, status);
 	}
+
+free:
 	kfree(palloc_buf);
 	return status;
 }

Signature · 1 line

2.33.1

Pavel Skripkin

2022-05-06 12:13 UTC #8 lore raw

Re: [PATCH v3 3/3] staging: rtl8712: add error handler in r8712_usbctrl_vendorreq()

Hi Wang,

Quoted 32 lines · Wang Cheng

When 'status' returned from usb_control_msg() is not equal to 'len', that usb_control_msg() is on partial failure, r8712_usbctrl_vendorreq() will treat partial reads as success.

Signed-off-by Wang Cheng <[email protected]>

---
  drivers/staging/rtl8712/usb_ops_linux.c | 21 ++++++++++++++-------
  1 file changed, 14 insertions(+), 7 deletions(-)

drivers/staging/rtl8712/usb_ops_linux.c +8 -7

index f984a5ab2c6f..b2181e1e2d38 100644
@@ -495,14 +495,21 @@ int r8712_usbctrl_vendorreq(struct intf_priv *pintfpriv, u8 request, u16 value,
  	}
  	status = usb_control_msg(udev, pipe, request, reqtype, value, index,
  				 pIo_buf, len, 500);
-	if (status > 0) {  /* Success this control transfer. */
-		if (requesttype == 0x01) {
-			/* For Control read transfer, we have to copy the read
-			 * data from pIo_buf to pdata.
-			 */
-			memcpy(pdata, pIo_buf,  status);
-		}
+	if (status < 0)
+		goto free;
+	if (status != len) {
+		status = -EREMOTEIO;
+		goto free;
+	}
+	/* Success this control transfer. */
+	if (requesttype == 0x01) {

drivers/staging/rtl8712/usb_ops_linux.c int r8712_usbctrl_vendorreq(struct intf_priv *pintfpriv, u8 request, u16 value, · line 515

Quoted 10 lines

drivers/staging/rtl8712/usb_ops_linux.c +6 -0

+		/* For Control read transfer, we have to copy the read
+		 * data from pIo_buf to pdata.
+		 */
+		memcpy(pdata, pIo_buf, status);
  	}
+
+free:
  	kfree(palloc_buf);
  	return status;
  }

Ah, here it is. This patch should be 1st in the series, since 1/3 now looks buggy.

With regards,
Pavel Skripkin