wifi: ath6kl: Check that the read operation returns a data length of 0

[PATCH] wifi: ath6kl: Check that the read operation returns a data length of 0

Posted by Edward Adam Davis 1 year, 3 months ago

If the data length returned by the device is 0, the read operation
should be considered a failure.

Reported-and-tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 drivers/net/wireless/ath/ath6kl/usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 5220809841a6..2a89bab81b24 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1034,6 +1034,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
 		ath6kl_err("Unable to read the bmi data from the device: %d\n",
 			   ret);
 		return ret;
+	} else {
+		ath6kl_err("Actual read the bmi data length is 0 from the device\n");
+		return -EIO;
 	}
 
 	return 0;
-- 
2.43.0

Re: [PATCH] wifi: ath6kl: Check that the read operation returns a data length of 0

Posted by Greg KH 1 year, 3 months ago

On Sun, Aug 25, 2024 at 03:10:03PM +0800, Edward Adam Davis wrote:
> If the data length returned by the device is 0, the read operation
> should be considered a failure.
> 
> Reported-and-tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>  drivers/net/wireless/ath/ath6kl/usb.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> index 5220809841a6..2a89bab81b24 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1034,6 +1034,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
>  		ath6kl_err("Unable to read the bmi data from the device: %d\n",
>  			   ret);
>  		return ret;
> +	} else {
> +		ath6kl_err("Actual read the bmi data length is 0 from the device\n");
> +		return -EIO;

Close, but not quite there.  ath6kl_usb_submit_ctrl_in() needs to verify
that the actual amount of data was read that was asked for.  If a short
read happens (or a long one), then an error needs to propagate out, not
just 0.  See the "note:" line in that function for what needs to be
properly checked.

hope this helps,

greg k-h

Re: [PATCH] wifi: ath6kl: Check that the read operation returns a data length of 0

Posted by Edward Adam Davis 1 year, 3 months ago

On Sun, 25 Aug 2024 09:25:37 +0200, Greg KH wrote:
> > If the data length returned by the device is 0, the read operation
> > should be considered a failure.
> >
> > Reported-and-tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> >  drivers/net/wireless/ath/ath6kl/usb.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > index 5220809841a6..2a89bab81b24 100644
> > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > @@ -1034,6 +1034,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
> >  		ath6kl_err("Unable to read the bmi data from the device: %d\n",
> >  			   ret);
> >  		return ret;
> > +	} else {
> > +		ath6kl_err("Actual read the bmi data length is 0 from the device\n");
> > +		return -EIO;
> 
> Close, but not quite there.  ath6kl_usb_submit_ctrl_in() needs to verify
> that the actual amount of data was read that was asked for.  If a short
> read happens (or a long one), then an error needs to propagate out, not
> just 0.  See the "note:" line in that function for what needs to be
> properly checked.
> 
> hope this helps,
Thanks for your analysis.
I have carefully read your analysis and I am not sure if the following
understanding is appropriate:
diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 2a89bab81b24..35884316a8c8 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -932,6 +932,15 @@ static int ath6kl_usb_submit_ctrl_in(struct ath6kl_usb *ar_usb,

        kfree(buf);

+       /* There are two types of read failure situations that need to be captured:
+        * 1. short read: ret < size && ret >= 0
+        * 2. long read: ret > size
+        * */
+       if (req == ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP && ret != size) {
+               ath6kl_warn("Actual read the data length is: %d, but input size is %d\n", ret, size);
+               return -EIO;
+       }
+
        return 0;
 }

BR,
Edward

Re: [PATCH] wifi: ath6kl: Check that the read operation returns a data length of 0

Posted by Greg KH 1 year, 3 months ago

On Sun, Aug 25, 2024 at 04:14:17PM +0800, Edward Adam Davis wrote:
> On Sun, 25 Aug 2024 09:25:37 +0200, Greg KH wrote:
> > > If the data length returned by the device is 0, the read operation
> > > should be considered a failure.
> > >
> > > Reported-and-tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > ---
> > >  drivers/net/wireless/ath/ath6kl/usb.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > > index 5220809841a6..2a89bab81b24 100644
> > > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > > @@ -1034,6 +1034,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
> > >  		ath6kl_err("Unable to read the bmi data from the device: %d\n",
> > >  			   ret);
> > >  		return ret;
> > > +	} else {
> > > +		ath6kl_err("Actual read the bmi data length is 0 from the device\n");
> > > +		return -EIO;
> > 
> > Close, but not quite there.  ath6kl_usb_submit_ctrl_in() needs to verify
> > that the actual amount of data was read that was asked for.  If a short
> > read happens (or a long one), then an error needs to propagate out, not
> > just 0.  See the "note:" line in that function for what needs to be
> > properly checked.
> > 
> > hope this helps,
> Thanks for your analysis.
> I have carefully read your analysis and I am not sure if the following
> understanding is appropriate:
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> index 2a89bab81b24..35884316a8c8 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -932,6 +932,15 @@ static int ath6kl_usb_submit_ctrl_in(struct ath6kl_usb *ar_usb,
> 
>         kfree(buf);

First off, this should be using usb_control_msg_send() instead of having
to roll their own buffer handling, right?

> +       /* There are two types of read failure situations that need to be captured:
> +        * 1. short read: ret < size && ret >= 0
> +        * 2. long read: ret > size
> +        * */
> +       if (req == ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP && ret != size) {
> +               ath6kl_warn("Actual read the data length is: %d, but input size is %d\n", ret, size);
> +               return -EIO;
> +       }

If you switch to usb_control_msg_send() this logic gets a lot simpler.
Perhaps do that instead?

If not, then you need to check for "short writes" or zero writes, see
the documentation for usb_control_msg() for what it returns.  Your
comment is not correct here, there are 3 different return "states" that
you need to handle.

And why are you caring about what the req type is?

thanks,

greg k-h

Re: [PATCH] wifi: ath6kl: Check that the read operation returns a data length of 0

Posted by Edward Adam Davis 1 year, 3 months ago

On Sun, 25 Aug 2024 10:34:00 +0200, Greg KH wrote:
> On Sun, Aug 25, 2024 at 04:14:17PM +0800, Edward Adam Davis wrote:
> > On Sun, 25 Aug 2024 09:25:37 +0200, Greg KH wrote:
> > > > If the data length returned by the device is 0, the read operation
> > > > should be considered a failure.
> > > >
> > > > Reported-and-tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > > ---
> > > >  drivers/net/wireless/ath/ath6kl/usb.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > index 5220809841a6..2a89bab81b24 100644
> > > > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > > > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > @@ -1034,6 +1034,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
> > > >  		ath6kl_err("Unable to read the bmi data from the device: %d\n",
> > > >  			   ret);
> > > >  		return ret;
> > > > +	} else {
> > > > +		ath6kl_err("Actual read the bmi data length is 0 from the device\n");
> > > > +		return -EIO;
> > >
> > > Close, but not quite there.  ath6kl_usb_submit_ctrl_in() needs to verify
> > > that the actual amount of data was read that was asked for.  If a short
> > > read happens (or a long one), then an error needs to propagate out, not
> > > just 0.  See the "note:" line in that function for what needs to be
> > > properly checked.
> > >
> > > hope this helps,
> > Thanks for your analysis.
> > I have carefully read your analysis and I am not sure if the following
> > understanding is appropriate:
> > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > index 2a89bab81b24..35884316a8c8 100644
> > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > @@ -932,6 +932,15 @@ static int ath6kl_usb_submit_ctrl_in(struct ath6kl_usb *ar_usb,
> >
> >         kfree(buf);
> 
> First off, this should be using usb_control_msg_send() instead of having
> to roll their own buffer handling, right?
I couldn't figure it out with what you said. 

ath6kl_usb_submit_ctrl_in() is similar to usb_control_msg_send(),
both calling usb_control_msg() to communicate with USB devices.

In the current issue, when executing an ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP
read request, the length of the data returned from the device is 0, which
is different from the expected length of the data to be read, resulting in
a warning.

ath6kl_usb_submit_ctrl_in()--->
	usb_control_msg()--->
		usb_internal_control_msg()

usb_internal_control_msg() will return the length of the data returned from
the device, usb_control_msg() return the length too, so in ath6kl_usb_submit_ctrl_in(),
we can filter out incorrect data lengths by judging the value of ret, such
as ret != Size situation.
> 
> > +       /* There are two types of read failure situations that need to be captured:
> > +        * 1. short read: ret < size && ret >= 0
> > +        * 2. long read: ret > size
> > +        * */
> > +       if (req == ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP && ret != size) {
> > +               ath6kl_warn("Actual read the data length is: %d, but input size is %d\n", ret, size);
> > +               return -EIO;
> > +       }
> 
> If you switch to usb_control_msg_send() this logic gets a lot simpler.
> Perhaps do that instead?
> 
> If not, then you need to check for "short writes" or zero writes, see
> the documentation for usb_control_msg() for what it returns.  Your
> comment is not correct here, there are 3 different return "states" that
> you need to handle.
> 
> And why are you caring about what the req type is?

BR,
Edward

Re: [PATCH] wifi: ath6kl: Check that the read operation returns a data length of 0

Posted by Greg KH 1 year, 3 months ago

On Sun, Aug 25, 2024 at 06:09:45PM +0800, Edward Adam Davis wrote:
> On Sun, 25 Aug 2024 10:34:00 +0200, Greg KH wrote:
> > On Sun, Aug 25, 2024 at 04:14:17PM +0800, Edward Adam Davis wrote:
> > > On Sun, 25 Aug 2024 09:25:37 +0200, Greg KH wrote:
> > > > > If the data length returned by the device is 0, the read operation
> > > > > should be considered a failure.
> > > > >
> > > > > Reported-and-tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> > > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > > > ---
> > > > >  drivers/net/wireless/ath/ath6kl/usb.c | 3 +++
> > > > >  1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > > index 5220809841a6..2a89bab81b24 100644
> > > > > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > > > > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > > @@ -1034,6 +1034,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
> > > > >  		ath6kl_err("Unable to read the bmi data from the device: %d\n",
> > > > >  			   ret);
> > > > >  		return ret;
> > > > > +	} else {
> > > > > +		ath6kl_err("Actual read the bmi data length is 0 from the device\n");
> > > > > +		return -EIO;
> > > >
> > > > Close, but not quite there.  ath6kl_usb_submit_ctrl_in() needs to verify
> > > > that the actual amount of data was read that was asked for.  If a short
> > > > read happens (or a long one), then an error needs to propagate out, not
> > > > just 0.  See the "note:" line in that function for what needs to be
> > > > properly checked.
> > > >
> > > > hope this helps,
> > > Thanks for your analysis.
> > > I have carefully read your analysis and I am not sure if the following
> > > understanding is appropriate:
> > > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > > index 2a89bab81b24..35884316a8c8 100644
> > > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > > @@ -932,6 +932,15 @@ static int ath6kl_usb_submit_ctrl_in(struct ath6kl_usb *ar_usb,
> > >
> > >         kfree(buf);
> > 
> > First off, this should be using usb_control_msg_send() instead of having
> > to roll their own buffer handling, right?
> I couldn't figure it out with what you said. 

Meaning this kfree() should not be needed if you use
usb_control_msg_send() (nor the allocation above it.)

> ath6kl_usb_submit_ctrl_in() is similar to usb_control_msg_send(),
> both calling usb_control_msg() to communicate with USB devices.

Yes, it's close, but not quite the same.

> In the current issue, when executing an ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP
> read request, the length of the data returned from the device is 0, which
> is different from the expected length of the data to be read, resulting in
> a warning.
> 
> ath6kl_usb_submit_ctrl_in()--->
> 	usb_control_msg()--->
> 		usb_internal_control_msg()
> 
> usb_internal_control_msg() will return the length of the data returned from
> the device, usb_control_msg() return the length too, so in ath6kl_usb_submit_ctrl_in(),
> we can filter out incorrect data lengths by judging the value of ret, such
> as ret != Size situation.

Then just do that type of check for that type of read request in the
code that does that call, not 2-3 layers deeper, no need for making this
more complex than needed.

Try removing both of these functions and just call usb functions
directly.

thanks,

greg k-h

Re: [PATCH] wifi: ath6kl: Check that the read operation returns a data length of 0

Posted by Edward Adam Davis 1 year, 3 months ago

On Sun, 25 Aug 2024 13:25:56 +0200, Greg KH wrote:
> On Sun, Aug 25, 2024 at 06:09:45PM +0800, Edward Adam Davis wrote:
> > On Sun, 25 Aug 2024 10:34:00 +0200, Greg KH wrote:
> > > On Sun, Aug 25, 2024 at 04:14:17PM +0800, Edward Adam Davis wrote:
> > > > On Sun, 25 Aug 2024 09:25:37 +0200, Greg KH wrote:
> > > > > > If the data length returned by the device is 0, the read operation
> > > > > > should be considered a failure.
> > > > > >
> > > > > > Reported-and-tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> > > > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > > > > ---
> > > > > >  drivers/net/wireless/ath/ath6kl/usb.c | 3 +++
> > > > > >  1 file changed, 3 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > > > index 5220809841a6..2a89bab81b24 100644
> > > > > > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > > > > > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > > > @@ -1034,6 +1034,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
> > > > > >  		ath6kl_err("Unable to read the bmi data from the device: %d\n",
> > > > > >  			   ret);
> > > > > >  		return ret;
> > > > > > +	} else {
> > > > > > +		ath6kl_err("Actual read the bmi data length is 0 from the device\n");
> > > > > > +		return -EIO;
> > > > >
> > > > > Close, but not quite there.  ath6kl_usb_submit_ctrl_in() needs to verify
> > > > > that the actual amount of data was read that was asked for.  If a short
> > > > > read happens (or a long one), then an error needs to propagate out, not
> > > > > just 0.  See the "note:" line in that function for what needs to be
> > > > > properly checked.
> > > > >
> > > > > hope this helps,
> > > > Thanks for your analysis.
> > > > I have carefully read your analysis and I am not sure if the following
> > > > understanding is appropriate:
> > > > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > index 2a89bab81b24..35884316a8c8 100644
> > > > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > > > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > > > @@ -932,6 +932,15 @@ static int ath6kl_usb_submit_ctrl_in(struct ath6kl_usb *ar_usb,
> > > >
> > > >         kfree(buf);
> > > 
> > > First off, this should be using usb_control_msg_send() instead of having
> > > to roll their own buffer handling, right?
> > I couldn't figure it out with what you said. 
> 
> Meaning this kfree() should not be needed if you use
> usb_control_msg_send() (nor the allocation above it.)
> 
> > ath6kl_usb_submit_ctrl_in() is similar to usb_control_msg_send(),
> > both calling usb_control_msg() to communicate with USB devices.
> 
> Yes, it's close, but not quite the same.
> 
> > In the current issue, when executing an ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP
> > read request, the length of the data returned from the device is 0, which
> > is different from the expected length of the data to be read, resulting in
> > a warning.
> > 
> > ath6kl_usb_submit_ctrl_in()--->
> > 	usb_control_msg()--->
> > 		usb_internal_control_msg()
> > 
> > usb_internal_control_msg() will return the length of the data returned from
> > the device, usb_control_msg() return the length too, so in ath6kl_usb_submit_ctrl_in(),
> > we can filter out incorrect data lengths by judging the value of ret, such
> > as ret != Size situation.
> 
> Then just do that type of check for that type of read request in the
> code that does that call, not 2-3 layers deeper, no need for making this
> more complex than needed.
> 
> Try removing both of these functions and just call usb functions
> directly.
I have tried following fix:
diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 5220809841a6..dc1f89ebb740 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1027,9 +1027,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
        int ret;
 
        /* get response */
-       ret = ath6kl_usb_submit_ctrl_in(ar_usb,
-                                       ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
-                                       0, 0, buf, len);
+       ret = usb_control_msg_recv(ar_usb->udev, 0, ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
+                                USB_DIR_IN | USB_TYPE_VENDOR |
+                                USB_RECIP_DEVICE, 0, 0, buf, len, 2000, GFP_KERNEL);
        if (ret) {
                ath6kl_err("Unable to read the bmi data from the device: %d\n",
                           ret);

I researched usb_control_msg_recv(), It handles the abnormal length of the
returned data, so using it directly can fix this warning.

BR,
Edward

[PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Edward Adam Davis 1 year, 3 months ago

ath6kl_usb_submit_ctrl_in() did not take into account the situation where
the length of the data read from the device is not equal to the len, and
such missing judgments will result in subsequent code using incorrect data.

usb_control_msg_recv() handles the abnormal length of the returned data,
so using it directly can fix this warning.

Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V2: Directly using USB functions

 drivers/net/wireless/ath/ath6kl/usb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 5220809841a6..dc1f89ebb740 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1027,9 +1027,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
 	int ret;
 
 	/* get response */
-	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
-					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
-					0, 0, buf, len);
+	ret = usb_control_msg_recv(ar_usb->udev, 0, ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
+				 USB_DIR_IN | USB_TYPE_VENDOR |
+				 USB_RECIP_DEVICE, 0, 0, buf, len, 2000, GFP_KERNEL);
 	if (ret) {
 		ath6kl_err("Unable to read the bmi data from the device: %d\n",
 			   ret);
-- 
2.43.0

Re: [PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Kalle Valo 1 year, 3 months ago

Edward Adam Davis <eadavis@qq.com> writes:

> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
>
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.
>
> Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>

Did you test this on real ath6kl hardware?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Edward Adam Davis 1 year, 3 months ago

On Mon, 26 Aug 2024 14:42:00 +0300, Kalle Valo wrote:
> > ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> > the length of the data read from the device is not equal to the len, and
> > such missing judgments will result in subsequent code using incorrect data.
> >
> > usb_control_msg_recv() handles the abnormal length of the returned data,
> > so using it directly can fix this warning.
> >
> > Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> 
> Did you test this on real ath6kl hardware?
I don't have ath6kl hardware, I have only tested it on a virtual machine.

BR,
Edward

Re: [PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Kalle Valo 1 year, 3 months ago

Edward Adam Davis <eadavis@qq.com> writes:

> On Mon, 26 Aug 2024 14:42:00 +0300, Kalle Valo wrote:
>> > ath6kl_usb_submit_ctrl_in() did not take into account the situation where
>> > the length of the data read from the device is not equal to the len, and
>> > such missing judgments will result in subsequent code using incorrect data.
>> >
>> > usb_control_msg_recv() handles the abnormal length of the returned data,
>> > so using it directly can fix this warning.
>> >
>> > Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
>> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
>> 
>> Did you test this on real ath6kl hardware?
>
> I don't have ath6kl hardware, I have only tested it on a virtual machine.

Virtual machine? I guess you mean syzbot? That gives no assurance if
this works on a real device or not. Please add to the commit message
"Compile tested only" so that we know it's untested.

And I have to warn that in wireless we are very reluctant to take syzbot
fixes which have not been tested on real hardware, they have caused
problems in the past.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
https://docs.kernel.org/process/submitting-patches.html

[PATCH V6 1/2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Edward Adam Davis 1 year, 3 months ago

ath6kl_usb_submit_ctrl_in() did not take into account the situation where
the length of the data read from the device is not equal to the len, and
such missing judgments will result in subsequent code using incorrect data.

usb_control_msg_recv() handles the abnormal length of the returned data,
so using it directly can fix "target's targ_info doesn't match the host's
targ_info" warning in ath6kl_bmi_get_target_info.

Note: Compile tested only, not tested on hardware, only tested on QEMU.

Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V1 -> V2: Directly using USB functions
V2 -> V3: Adjust indentation style
V3 -> V4: Adjust indentation style
V4 -> V5: Update comments, add warning info
V5 -> V6: Update comments

 drivers/net/wireless/ath/ath6kl/usb.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 5220809841a6..0458b5a078e1 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1027,9 +1027,10 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
 	int ret;
 
 	/* get response */
-	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
-					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
-					0, 0, buf, len);
+	ret = usb_control_msg_recv(ar_usb->udev, 0,
+				   ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
+				   USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+				   0, 0, buf, len, 2000, GFP_KERNEL);
 	if (ret) {
 		ath6kl_err("Unable to read the bmi data from the device: %d\n",
 			   ret);
-- 
2.43.0

Re: [PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Greg KH 1 year, 3 months ago

On Sun, Aug 25, 2024 at 10:21:49PM +0800, Edward Adam Davis wrote:
> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
> 
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.
> 
> Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> V2: Directly using USB functions
> 
>  drivers/net/wireless/ath/ath6kl/usb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> index 5220809841a6..dc1f89ebb740 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1027,9 +1027,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
>  	int ret;
>  
>  	/* get response */
> -	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
> -					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> -					0, 0, buf, len);

By removing this call, there is now only one call left to
ath6kl_usb_submit_ctrl_in(), so that probably can also be unwrapped in a
second patch in this series, right?

> +	ret = usb_control_msg_recv(ar_usb->udev, 0, ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> +				 USB_DIR_IN | USB_TYPE_VENDOR |
> +				 USB_RECIP_DEVICE, 0, 0, buf, len, 2000, GFP_KERNEL);

As was pointed out, this is a very odd indentation style.

thanks,

greg k-h

Re: [PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Edward Adam Davis 1 year, 3 months ago

Hi Greg KH and Sergey,

On Mon, 26 Aug 2024 07:04:00 +0200, Greg KH wrote:
> > ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> > the length of the data read from the device is not equal to the len, and
> > such missing judgments will result in subsequent code using incorrect data.
> >
> > usb_control_msg_recv() handles the abnormal length of the returned data,
> > so using it directly can fix this warning.
> >
> > Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> > V2: Directly using USB functions
> >
> >  drivers/net/wireless/ath/ath6kl/usb.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> > index 5220809841a6..dc1f89ebb740 100644
> > --- a/drivers/net/wireless/ath/ath6kl/usb.c
> > +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> > @@ -1027,9 +1027,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
> >  	int ret;
> >
> >  	/* get response */
> > -	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
> > -					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> > -					0, 0, buf, len);
> 
> By removing this call, there is now only one call left to
> ath6kl_usb_submit_ctrl_in(), so that probably can also be unwrapped in a
> second patch in this series, right?
Sorry, I didn't clarify what you said.
> 
> > +	ret = usb_control_msg_recv(ar_usb->udev, 0, ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> > +				 USB_DIR_IN | USB_TYPE_VENDOR |
> > +				 USB_RECIP_DEVICE, 0, 0, buf, len, 2000, GFP_KERNEL);
> 
> As was pointed out, this is a very odd indentation style.
I will send V3 patch to adjust the indentation style.

BR,
Edward

[PATCH V3] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Edward Adam Davis 1 year, 3 months ago

ath6kl_usb_submit_ctrl_in() did not take into account the situation where
the length of the data read from the device is not equal to the len, and
such missing judgments will result in subsequent code using incorrect data.

usb_control_msg_recv() handles the abnormal length of the returned data,
so using it directly can fix this warning.

Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V2 -> V3: Adjust indentation style

 drivers/net/wireless/ath/ath6kl/usb.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 5220809841a6..5b1ce4f9ed54 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1027,9 +1027,11 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
 	int ret;
 
 	/* get response */
-	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
-					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
-					0, 0, buf, len);
+	ret = usb_control_msg_recv(ar_usb->udev, 0,
+				ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
+				USB_DIR_IN | USB_TYPE_VENDOR |
+				USB_RECIP_DEVICE, 0, 0, buf, len, 2000,
+				GFP_KERNEL);
 	if (ret) {
 		ath6kl_err("Unable to read the bmi data from the device: %d\n",
 			   ret);
-- 
2.43.0

Re: [PATCH V3] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Greg KH 1 year, 3 months ago

On Mon, Aug 26, 2024 at 07:19:09PM +0800, Edward Adam Davis wrote:
> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
> 
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.
> 
> Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> V2 -> V3: Adjust indentation style
> 
>  drivers/net/wireless/ath/ath6kl/usb.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> index 5220809841a6..5b1ce4f9ed54 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1027,9 +1027,11 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
>  	int ret;
>  
>  	/* get response */
> -	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
> -					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> -					0, 0, buf, len);
> +	ret = usb_control_msg_recv(ar_usb->udev, 0,
> +				ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> +				USB_DIR_IN | USB_TYPE_VENDOR |
> +				USB_RECIP_DEVICE, 0, 0, buf, len, 2000,
> +				GFP_KERNEL);

This should be:

	ret = usb_control_msg_recv(ar_usb->udev, 0,
				ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
				USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
				0, 0, buf, len, 2000, GFP_KERNEL);

right?  Keep the | values on the same line.

thanks,

greg k-h

Re: [PATCH V3] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Greg KH 1 year, 3 months ago

On Mon, Aug 26, 2024 at 07:19:09PM +0800, Edward Adam Davis wrote:
> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
> 
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.
> 
> Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> V2 -> V3: Adjust indentation style
> 
>  drivers/net/wireless/ath/ath6kl/usb.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> index 5220809841a6..5b1ce4f9ed54 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1027,9 +1027,11 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
>  	int ret;
>  
>  	/* get response */
> -	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
> -					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> -					0, 0, buf, len);

Again, please make this a patch series, with the second one removing
ath6kl_usb_submit_ctrl_in() and moving to use usb_control_msg_recv() for
that too.

thanks,

greg k-h

[PATCH V4 1/2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Edward Adam Davis 1 year, 3 months ago

ath6kl_usb_submit_ctrl_in() did not take into account the situation where
the length of the data read from the device is not equal to the len, and
such missing judgments will result in subsequent code using incorrect data.

usb_control_msg_recv() handles the abnormal length of the returned data,
so using it directly can fix this warning.

Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V4: Adjust indentation style

 drivers/net/wireless/ath/ath6kl/usb.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 5220809841a6..0458b5a078e1 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1027,9 +1027,10 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
 	int ret;
 
 	/* get response */
-	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
-					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
-					0, 0, buf, len);
+	ret = usb_control_msg_recv(ar_usb->udev, 0,
+				ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
+				USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+				0, 0, buf, len, 2000, GFP_KERNEL);
 	if (ret) {
 		ath6kl_err("Unable to read the bmi data from the device: %d\n",
 			   ret);
-- 
2.43.0

[PATCH V4 1/2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Edward Adam Davis 1 year, 3 months ago

ath6kl_usb_submit_ctrl_in() did not take into account the situation where
the length of the data read from the device is not equal to the len, and
such missing judgments will result in subsequent code using incorrect data.

usb_control_msg_recv() handles the abnormal length of the returned data,
so using it directly can fix this warning.

Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V4: Adjust indentation style

 drivers/net/wireless/ath/ath6kl/usb.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 5220809841a6..0458b5a078e1 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1027,9 +1027,10 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
 	int ret;
 
 	/* get response */
-	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
-					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
-					0, 0, buf, len);
+	ret = usb_control_msg_recv(ar_usb->udev, 0,
+				ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
+				USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+				0, 0, buf, len, 2000, GFP_KERNEL);
 	if (ret) {
 		ath6kl_err("Unable to read the bmi data from the device: %d\n",
 			   ret);
-- 
2.43.0

Re: [PATCH V4 1/2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Greg KH 1 year, 3 months ago

On Mon, Aug 26, 2024 at 08:29:56PM +0800, Edward Adam Davis wrote:
> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
> 
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.
> 
> Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> V4: Adjust indentation style
> 

Please list all of the version changes here.

Also, I got 2 copies of this, did something go wrong on your side?

thanks,

greg k-h

Re: [PATCH V4 1/2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Greg KH 1 year, 3 months ago

On Mon, Aug 26, 2024 at 08:29:56PM +0800, Edward Adam Davis wrote:
> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
> 
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.

what warning?

Re: [PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Sergei Shtylyov 1 year, 3 months ago

On 8/25/24 5:21 PM, Edward Adam Davis wrote:

> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
> 
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.
> 
> Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
[...]

> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> index 5220809841a6..dc1f89ebb740 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1027,9 +1027,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
>  	int ret;
>  
>  	/* get response */
> -	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
> -					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> -					0, 0, buf, len);
	ret = usb_control_msg_recv(ar_usb->udev, 0, ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
				 USB_DIR_IN | USB_TYPE_VENDOR |

   Strange alignment style... If you're not going to reuse the old style,
why this trailing space before USB_DIR_IN?

> +				 USB_RECIP_DEVICE, 0, 0, buf, len, 2000, GFP_KERNEL);

   Same here...

[...]

MBR, Sergey

Re: [PATCH V2] wifi: ath6kl: Replace ath6kl_usb_submit_ctrl_in with usb_control_msg_recv

Posted by Sergei Shtylyov 1 year, 3 months ago

Hello!

   Oops, sent a wrong draft... :-/

On 8/25/24 5:21 PM, Edward Adam Davis wrote:

> ath6kl_usb_submit_ctrl_in() did not take into account the situation where
> the length of the data read from the device is not equal to the len, and
> such missing judgments will result in subsequent code using incorrect data.
> 
> usb_control_msg_recv() handles the abnormal length of the returned data,
> so using it directly can fix this warning.
> 
> Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
[...]

> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
> index 5220809841a6..dc1f89ebb740 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1027,9 +1027,9 @@ static int ath6kl_usb_bmi_read(struct ath6kl *ar, u8 *buf, u32 len)
>  	int ret;
>  
>  	/* get response */
> -	ret = ath6kl_usb_submit_ctrl_in(ar_usb,
> -					ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> -					0, 0, buf, len);
> +	ret = usb_control_msg_recv(ar_usb->udev, 0, ATH6KL_USB_CONTROL_REQ_RECV_BMI_RESP,
> +				 USB_DIR_IN | USB_TYPE_VENDOR |


   Strange alignment style... If you're not going to reuse the old style,
why this trailing space before USB_DIR_IN?

> +				 USB_RECIP_DEVICE, 0, 0, buf, len, 2000, GFP_KERNEL);

   Same here...

[...]

MBR, Sergey