Hello Bryan Wu,
The patch c6994e6f067c: "USB: gadget: add USB Audio Gadget driver"
from Jun 3, 2009, leads to the following static checker warning:
drivers/usb/gadget/function/f_uac1.c:371 f_audio_complete()
error: __memcpy() '&data' too small (4 vs u32max)
drivers/usb/gadget/function/f_uac1.c
358 static void f_audio_complete(struct usb_ep *ep, struct usb_request *req)
359 {
360 struct f_audio *audio = req->context;
361 int status = req->status;
362 u32 data = 0;
^^^^^^^^
data is a u32.
363 struct usb_ep *out_ep = audio->out_ep;
364
365 switch (status) {
366
367 case 0: /* normal completion? */
368 if (ep == out_ep)
369 f_audio_out_ep_complete(ep, req);
370 else if (audio->set_con) {
371 memcpy(&data, req->buf, req->length);
^^^^^^^^^^^
Back in 2014 Kees ran a USB fuzzer on the kernel. My take on that was
that req->length could not be trusted and had to be capped so I changed
Smatch to complain about these. But after a while I decided I was not
sure enough of the rules so I just ignore those bugs these days... What
are the rules?
372 audio->set_con->set(audio->set_con, audio->set_cmd,
373 le16_to_cpu(data));
Doing le16_to_cpu() on a u32 is an endian bug.
374 audio->set_con = NULL;
375 }
376 break;
377 default:
378 break;
379 }
380 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
