From: Dan Carpenter <dan.carpenter@oracle.com>
To: andrzej.p@samsung.com
Cc: linux-usb@vger.kernel.org
Subject: [bug report] usb: gadget: f_fs: OS descriptors support
Date: Sat, 8 Jun 2019 12:26:00 +0300 [thread overview]
Message-ID: <20190608092600.GD28890@mwanda> (raw)
Hello Andrzej Pietrasiewicz,
The patch f0175ab51993: "usb: gadget: f_fs: OS descriptors support"
from Jul 9, 2014, leads to the following static checker warning:
drivers/usb/gadget/function/f_fs.c:2992 __ffs_func_bind_do_os_desc()
error: 'ext_prop->data_len' from user is not capped properly
drivers/usb/gadget/function/f_fs.c
2961 ARRAY_SIZE(desc->CompatibleID) +
2962 ARRAY_SIZE(desc->SubCompatibleID));
2963 length = sizeof(*desc);
2964 }
2965 break;
2966 case FFS_OS_DESC_EXT_PROP: {
2967 struct usb_ext_prop_desc *desc = data;
2968 struct usb_os_desc_table *t;
2969 struct usb_os_desc_ext_prop *ext_prop;
2970 char *ext_prop_name;
2971 char *ext_prop_data;
2972
2973 t = &func->function.os_desc_table[h->interface];
2974 t->if_id = func->interfaces_nums[h->interface];
2975
2976 ext_prop = func->ffs->ms_os_descs_ext_prop_avail;
2977 func->ffs->ms_os_descs_ext_prop_avail += sizeof(*ext_prop);
2978
2979 ext_prop->type = le32_to_cpu(desc->dwPropertyDataType);
2980 ext_prop->name_len = le16_to_cpu(desc->wPropertyNameLength);
2981 ext_prop->data_len = le32_to_cpu(*(__le32 *)
2982 usb_ext_prop_data_len_ptr(data, ext_prop->name_len));
Smatch is very suspicious of "ext_prop->data_len".
2983 length = ext_prop->name_len + ext_prop->data_len + 14;
2984
2985 ext_prop_name = func->ffs->ms_os_descs_ext_prop_name_avail;
2986 func->ffs->ms_os_descs_ext_prop_name_avail +=
2987 ext_prop->name_len;
2988
2989 ext_prop_data = func->ffs->ms_os_descs_ext_prop_data_avail;
2990 func->ffs->ms_os_descs_ext_prop_data_avail +=
2991 ext_prop->data_len;
2992 memcpy(ext_prop_data,
2993 usb_ext_prop_data_ptr(data, ext_prop->name_len),
2994 ext_prop->data_len);
^^^^^^^^^^^^^^^^^^
so it complians that this memcpy() can overflow. That seems like maybe
a real issue?
2995 /* unicode data reported to the host as "WCHAR"s */
2996 switch (ext_prop->type) {
2997 case USB_EXT_PROP_UNICODE:
2998 case USB_EXT_PROP_UNICODE_ENV:
2999 case USB_EXT_PROP_UNICODE_LINK:
3000 case USB_EXT_PROP_UNICODE_MULTI:
3001 ext_prop->data_len *= 2;
3002 break;
3003 }
3004 ext_prop->data = ext_prop_data;
regards,
dan carpenter
reply other threads:[~2019-06-08 9:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190608092600.GD28890@mwanda \
--to=dan.carpenter@oracle.com \
--cc=andrzej.p@samsung.com \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).