We shouldn't accept malformed set_line_coding requests.
All values were taken from table 17 (section 6.3.11) of the cdc1.2 spec
available at http://www.usb.org/developers/docs/devclass_docs/
The table is in the file PTSN120.pdf.
Signed-off-by: Tal Shorer <tal.sho...@gmail.com>
---
drivers/usb/gadget/function/f_acm.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/function/f_acm.c
b/drivers/usb/gadget/function/f_acm.c
index 5e3828d..e023313 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -326,13 +326,22 @@ static void acm_complete_set_line_coding(struct usb_ep
*ep,
struct usb_cdc_line_coding *value = req->buf;
/* REVISIT: we currently just remember this data.
- * If we change that, (a) validate it first, then
- * (b) update whatever hardware needs updating,
- * (c) worry about locking. This is information on
- * the order of 9600-8-N-1 ... most of which means
- * nothing unless we control a real RS232 line.
- */
- acm->port_line_coding = *value;
+ * If we change that,
+ * (a) update whatever hardware needs updating,
+ * (b) worry about locking. This is information on
+ * the order of 9600-8-N-1 ... most of which means
+ * nothing unless we control a real RS232 line.
+ */
+ dev_dbg(&cdev->gadget->dev,
+ "acm ttyGS%d set_line_coding: %d %d %d %d\n",
+ acm->port_num, le32_to_cpu(value->dwDTERate),
+ value->bCharFormat, value->bParityType,
+ value->bDataBits);
+ if (value->bCharFormat > 2 || value->bParityType > 4 ||
+ value->bDataBits < 5 || value->bDataBits > 8)
+ usb_ep_set_halt(ep);
+ else
+ acm->port_line_coding = *value;
}
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
