[syzbot] [wireless?] [usb?] WARNING in ath6kl_bmi_get_target_info (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 1722389b0d86 Merge tag 'net-6.11-rc1' of git://git.kernel...
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=1467299d980000
kernel config: https://syzkaller.appspot.com/x/.config?x=e3044dca4d5f6dbe
dashboard link: https://syzkaller.appspot.com/bug?extid=92c6dd14aaa230be6855
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=166a0275980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13552c6d980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/78a5695ed7e2/disk-1722389b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1507b4c5000d/vmlinux-1722389b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/449aa9e94d6b/bzImage-1722389b.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+92c6dd...@syzkaller.appspotmail.com

usb 1-1: new high-speed USB device number 2 using dummy_hcd
usb 1-1: New USB device found, idVendor=0cf3, idProduct=9375, bcdDevice=1a.9e
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2343 at drivers/net/wireless/ath/ath6kl/bmi.c:90 ath6kl_bmi_get_target_info+0x4f5/0x5b0 drivers/net/wireless/ath/ath6kl/bmi.c:90
Modules linked in:
CPU: 0 UID: 0 PID: 2343 Comm: kworker/0:2 Not tainted 6.10.0-syzkaller-g1722389b0d86 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Workqueue: usb_hub_wq hub_event
RIP: 0010:ath6kl_bmi_get_target_info+0x4f5/0x5b0 drivers/net/wireless/ath/ath6kl/bmi.c:90
Code: 77 fc ff ff e8 4c fa b1 fd be 08 00 00 00 bd f3 ff ff ff 48 c7 c7 20 db 7f 87 e8 26 42 fe ff e9 5c fd ff ff e8 2c fa b1 fd 90 <0f> 0b 90 bd ea ff ff ff e9 49 fd ff ff e8 79 ec 06 fe e9 e7 fb ff
RSP: 0018:ffffc900042eef48 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8881135c0e20 RCX: ffffffff83a15e8a
RDX: ffff88811394d700 RSI: ffffffff83a16014 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000005 R09: 000000000000000c
R10: 0000000000000000 R11: ffffffff81004e0a R12: ffffc900042ef058
R13: 1ffff9200085ddeb R14: ffff8881135c0e50 R15: ffffc900042ef05c
FS: 0000000000000000(0000) GS:ffff8881f6200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055ea8cfc1b18 CR3: 0000000115c00000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ath6kl_core_init+0x1a0/0x11a0 drivers/net/wireless/ath/ath6kl/core.c:101
ath6kl_usb_probe+0xcd2/0x1450 drivers/net/wireless/ath/ath6kl/usb.c:1168
usb_probe_interface+0x309/0x9d0 drivers/usb/core/driver.c:399
call_driver_probe drivers/base/dd.c:578 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:457
__device_attach+0x1e8/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:532
device_add+0x114b/0x1a70 drivers/base/core.c:3679
usb_set_configuration+0x10cb/0x1c50 drivers/usb/core/message.c:2210
usb_generic_driver_probe+0xb1/0x110 drivers/usb/core/generic.c:254
usb_probe_device+0xec/0x3e0 drivers/usb/core/driver.c:294
call_driver_probe drivers/base/dd.c:578 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:457
__device_attach+0x1e8/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:532
device_add+0x114b/0x1a70 drivers/base/core.c:3679
usb_new_device+0xd90/0x1a10 drivers/usb/core/hub.c:2651
hub_port_connect drivers/usb/core/hub.c:5521 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5661 [inline]
port_event drivers/usb/core/hub.c:5821 [inline]
hub_event+0x2e66/0x4f50 drivers/usb/core/hub.c:5903
process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
process_scheduled_works kernel/workqueue.c:3312 [inline]
worker_thread+0x6c8/0xf20 kernel/workqueue.c:3390
kthread+0x2c1/0x3a0 kernel/kthread.c:389
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Edward Adam Davis]

Actual read the bmi data length is 0 from the device

#syz test: upstream master

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;

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+92c6dd...@syzkaller.appspotmail.com
Tested-by: syzbot+92c6dd...@syzkaller.appspotmail.com

Tested on:

commit: 780bdc1b Merge tag '6.11-rc5-server-fixes' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17b4ec33980000
kernel config: https://syzkaller.appspot.com/x/.config?x=31bb2857b4a82509

dashboard link: https://syzkaller.appspot.com/bug?extid=92c6dd14aaa230be6855
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40

patch: https://syzkaller.appspot.com/x/patch.diff?x=10a3b015980000

Note: testing is done by a robot and is best-effort only.

[Edward Adam Davis]

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

Reported-and-tested-by: syzbot+92c6dd...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@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

[Greg KH]

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

[Edward Adam Davis]

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

[Greg KH]

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

[Edward Adam Davis]

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

[Greg KH]

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

[Edward Adam Davis]

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

[Edward Adam Davis]

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+92c6dd...@syzkaller.appspotmail.com

Signed-off-by: Edward Adam Davis <ead...@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

[Greg KH]

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+92c6dd...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@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

[Sergei Shtylyov]

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+92c6dd...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@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

[Sergei Shtylyov]

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+92c6dd...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@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);

[Edward Adam Davis]

Hi Greg KH and Sergey,

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

[Greg KH]

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+92c6dd...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@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

[Edward Adam Davis]

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+92c6dd...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@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);

[Greg KH]

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+92c6dd...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@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

[Kalle Valo]

Edward Adam Davis <ead...@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+92c6dd...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@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

[Edward Adam Davis]

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.

Suggested-by: Greg KH <gre...@linuxfoundation.org>

Signed-off-by: Edward Adam Davis <ead...@qq.com>
---

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

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 0458b5a078e1..b1fc66d823b8 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -901,40 +901,6 @@ static int ath6kl_usb_submit_ctrl_out(struct ath6kl_usb *ar_usb,
return 0;
}

-static int ath6kl_usb_submit_ctrl_in(struct ath6kl_usb *ar_usb,
- u8 req, u16 value, u16 index, void *data,
- u32 size)
-{
- u8 *buf = NULL;
- int ret;
-
- if (size > 0) {
- buf = kmalloc(size, GFP_KERNEL);
- if (buf == NULL)
- return -ENOMEM;
- }
-
- /* note: if successful returns number of bytes transfered */
- ret = usb_control_msg(ar_usb->udev,
- usb_rcvctrlpipe(ar_usb->udev, 0),
- req,
- USB_DIR_IN | USB_TYPE_VENDOR |
- USB_RECIP_DEVICE, value, index, buf,
- size, 2000);
-
- if (ret < 0) {
- ath6kl_warn("Failed to read usb control message: %d\n", ret);
- kfree(buf);
- return ret;
- }
-
- memcpy((u8 *) data, buf, size);
-
- kfree(buf);
-
- return 0;
-}
-
static int ath6kl_usb_ctrl_msg_exchange(struct ath6kl_usb *ar_usb,
u8 req_val, u8 *req_buf, u32 req_len,
u8 resp_val, u8 *resp_buf, u32 *resp_len)
@@ -954,8 +920,9 @@ static int ath6kl_usb_ctrl_msg_exchange(struct ath6kl_usb *ar_usb,
}

/* get response */
- ret = ath6kl_usb_submit_ctrl_in(ar_usb, resp_val, 0, 0,
- resp_buf, *resp_len);
+ ret = usb_control_msg_recv(ar_usb->udev, 0, resp_val,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ 0, 0, resp_buf, *resp_len, 2000, GFP_KERNEL);

return ret;
}
--
2.43.0

[Edward Adam Davis]

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+92c6dd...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@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);

[Edward Adam Davis]

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.

Suggested-by: Greg KH <gre...@linuxfoundation.org>

Signed-off-by: Edward Adam Davis <ead...@qq.com>
---

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

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 0458b5a078e1..b1fc66d823b8 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c

/* get response */

- ret = ath6kl_usb_submit_ctrl_in(ar_usb, resp_val, 0, 0,
- resp_buf, *resp_len);

+ ret = usb_control_msg_recv(ar_usb->udev, 0, resp_val,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,

[Edward Adam Davis]

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+92c6dd...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@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,

[Edward Adam Davis]

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+92c6dd...@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <ead...@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

[Greg KH]

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?

[Greg KH]

You didn't run checkpatch on this :(

[Greg KH]

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+92c6dd...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@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

[Edward Adam Davis]

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.

Reported-by: syzbot+92c6dd...@syzkaller.appspotmail.com

Signed-off-by: Edward Adam Davis <ead...@qq.com>
---

V1: If the data length returned by the device is 0 return failure

V2: Directly using USB functions

V3: Adjust indentation style
V4: Adjust indentation style
V5: Update comments, add warning info

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,

[Edward Adam Davis]

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.

Suggested-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
drivers/net/wireless/ath/ath6kl/usb.c | 39 +++------------------------
1 file changed, 3 insertions(+), 36 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c

index 0458b5a078e1..1a5fb2561fef 100644

return ret;
}
--
2.43.0

[Kalle Valo]

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

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

[Edward Adam Davis]

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+92c6dd...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@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,

[Edward Adam Davis]

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.

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

Suggested-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Signed-off-by: Edward Adam Davis <ead...@qq.com>

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

diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 0458b5a078e1..1a5fb2561fef 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c

/* get response */

- ret = ath6kl_usb_submit_ctrl_in(ar_usb, resp_val, 0, 0,
- resp_buf, *resp_len);

+ ret = usb_control_msg_recv(ar_usb->udev, 0, resp_val,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,