Headline
CVE-2022-3903: [git:media_stage/master] media: mceusb: Use new usb_control_msg_*() routines
An incorrect read request flaw was found in the Infrared Transceiver USB driver in the Linux kernel. This issue occurs when a user attaches a malicious USB device. A local user could use this flaw to starve the resources, causing denial of service or potentially crashing the system.
From: Mauro Carvalho Chehab [email protected] To: [email protected] Cc: Rondreis [email protected], Alan Stern [email protected], Sean Young [email protected], [email protected] Subject: [git:media_stage/master] media: mceusb: Use new usb_control_msg_*() routines Date: Sat, 24 Sep 2022 05:49:45 +0000 [thread overview] Message-ID: [email protected] (raw)
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: mceusb: Use new usb_control_msg_*() routines Author: Alan Stern [email protected] Date: Fri Aug 26 21:31:40 2022 +0200
Automatic kernel fuzzing led to a WARN about invalid pipe direction in the mceusb driver:
------------[ cut here ]------------ usb 6-1: BOGUS control dir, pipe 80000380 doesn’t match bRequestType 40 WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410 usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41 RSP: 0018:ffffc900032becf0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000 RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90 RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000 R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000 R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0 Call Trace: <TASK> usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline] mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807
The reason for the warning is clear enough; the driver sends an unusual read request on endpoint 0 but does not set the USB_DIR_IN bit in the bRequestType field.
More importantly, the whole situation can be avoided and the driver simplified by converting it over to the relatively new usb_control_msg_recv() and usb_control_msg_send() routines. That’s what this fix does.
Reported-and-tested-by: Rondreis [email protected] Link: https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA@mail.gmail.com/
Signed-off-by: Alan Stern [email protected] Cc: [email protected] Signed-off-by: Sean Young [email protected] Signed-off-by: Mauro Carvalho Chehab [email protected]
drivers/media/rc/mceusb.c | 35 +++++++++++++±-------------------- 1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c index 0834d5f866fd…39d2b03e2631 100644 — a/drivers/media/rc/mceusb.c +++ b/drivers/media/rc/mceusb.c @@ -1416,42 +1416,37 @@ static void mceusb_gen1_init(struct mceusb_dev *ir) { int ret; struct device *dev = ir->dev; - char *data;
- data = kzalloc(USB_CTRL_MSG_SZ, GFP_KERNEL);
- if (!data) {
dev\_err(dev, "%s: memory allocation failed!", \_\_func\_\_);return;- }
char data[USB_CTRL_MSG_SZ];
/* * This is a strange one. Windows issues a set address to the device * on the receive control pipe and expect a certain value pair back */ - ret = usb_control_msg(ir->usbdev, usb_rcvctrlpipe(ir->usbdev, 0),
USB\_REQ\_SET\_ADDRESS, USB\_TYPE\_VENDOR, 0, 0,data, USB\_CTRL\_MSG\_SZ, 3000);
ret = usb_control_msg_recv(ir->usbdev, 0, USB_REQ_SET_ADDRESS,
USB\_DIR\_IN | USB\_TYPE\_VENDOR,0, 0, data, USB\_CTRL\_MSG\_SZ, 3000,GFP\_KERNEL);dev_dbg(dev, "set address - ret = %d", ret); dev_dbg(dev, "set address - data[0] = %d, data[1] = %d", data[0], data[1]);
/* set feature: bit rate 38400 bps */ - ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
USB\_REQ\_SET\_FEATURE, USB\_TYPE\_VENDOR,0xc04e, 0x0000, NULL, 0, 3000);
ret = usb_control_msg_send(ir->usbdev, 0,
USB\_REQ\_SET\_FEATURE, USB\_TYPE\_VENDOR,0xc04e, 0x0000, NULL, 0, 3000, GFP\_KERNEL);dev_dbg(dev, "set feature - ret = %d", ret);
/* bRequest 4: set char length to 8 bits */ - ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
4, USB\_TYPE\_VENDOR,0x0808, 0x0000, NULL, 0, 3000);
ret = usb_control_msg_send(ir->usbdev, 0,
4, USB\_TYPE\_VENDOR,0x0808, 0x0000, NULL, 0, 3000, GFP\_KERNEL);dev_dbg(dev, "set char length - retB = %d", ret);
/* bRequest 2: set handshaking to use DTR/DSR */ - ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
2, USB\_TYPE\_VENDOR,0x0000, 0x0100, NULL, 0, 3000);
ret = usb_control_msg_send(ir->usbdev, 0,
2, USB\_TYPE\_VENDOR,0x0000, 0x0100, NULL, 0, 3000, GFP\_KERNEL);dev_dbg(dev, "set handshake - retC = %d", ret);
/* device resume */ @@ -1459,8 +1454,6 @@ static void mceusb_gen1_init(struct mceusb_dev *ir)
/* get hw/sw revision? */ mce_command_out(ir, GET_REVISION, sizeof(GET_REVISION)); -
- kfree(data); }
static void mceusb_gen2_init(struct mceusb_dev *ir)
reply other threads:\[~2022-09-24 6:43 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 \ –[email protected] \ –[email protected] \ –[email protected] \ –[email protected] \ –[email protected] \ –[email protected] \ –[email protected] \ –[email protected] \ /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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.
Related news
Ubuntu Security Notice 6256-1 - Jiasheng Jiang discovered that the HSA Linux kernel driver for AMD Radeon GPU devices did not properly validate memory allocation in certain situations, leading to a null pointer dereference vulnerability. A local attacker could use this to cause a denial of service. Zheng Wang discovered that the Intel i915 graphics driver in the Linux kernel did not properly handle certain error conditions, leading to a double-free. A local attacker could possibly use this to cause a denial of service.
Ubuntu Security Notice 6222-1 - Jiasheng Jiang discovered that the HSA Linux kernel driver for AMD Radeon GPU devices did not properly validate memory allocation in certain situations, leading to a null pointer dereference vulnerability. A local attacker could use this to cause a denial of service. Zheng Wang discovered that the Intel i915 graphics driver in the Linux kernel did not properly handle certain error conditions, leading to a double-free. A local attacker could possibly use this to cause a denial of service.
Dell VxRail versions earlier than 7.0.450, contain(s) an OS command injection vulnerability in VxRail Manager. A local authenticated attacker could potentially exploit this vulnerability, leading to the execution of arbitrary OS commands on the application's underlying OS, with the privileges of the vulnerable application. Exploitation may lead to a system take over by an attacker.
Ubuntu Security Notice 6093-1 - It was discovered that the Traffic-Control Index implementation in the Linux kernel did not properly perform filter deactivation in some situations. A local attacker could possibly use this to gain elevated privileges. Please note that with the fix for this CVE, kernel support for the TCINDEX classifier has been removed. It was discovered that the Traffic-Control Index implementation in the Linux kernel contained a use-after-free vulnerability. A local attacker could use this to cause a denial of service or possibly execute arbitrary code.
Ubuntu Security Notice 6031-1 - It was discovered that the Traffic-Control Index implementation in the Linux kernel contained a use-after-free vulnerability. A local attacker could use this to cause a denial of service or possibly execute arbitrary code. It was discovered that the Integrity Measurement Architecture implementation in the Linux kernel did not properly enforce policy in certain conditions. A privileged attacker could use this to bypass Kernel lockdown restrictions.
Ubuntu Security Notice 6030-1 - It was discovered that the Traffic-Control Index implementation in the Linux kernel contained a use-after-free vulnerability. A local attacker could use this to cause a denial of service or possibly execute arbitrary code. It was discovered that the System V IPC implementation in the Linux kernel did not properly handle large shared memory counts. A local attacker could use this to cause a denial of service.
Ubuntu Security Notice 6029-1 - It was discovered that the Traffic-Control Index implementation in the Linux kernel contained a use-after-free vulnerability. A local attacker could use this to cause a denial of service or possibly execute arbitrary code. It was discovered that the infrared transceiver USB driver did not properly handle USB control messages. A local attacker with physical access could plug in a specially crafted USB device to cause a denial of service.
Ubuntu Security Notice 6027-1 - It was discovered that the Traffic-Control Index implementation in the Linux kernel contained a use-after-free vulnerability. A local attacker could use this to cause a denial of service or possibly execute arbitrary code. Jiasheng Jiang discovered that the HSA Linux kernel driver for AMD Radeon GPU devices did not properly validate memory allocation in certain situations, leading to a null pointer dereference vulnerability. A local attacker could use this to cause a denial of service.
Ubuntu Security Notice 6014-1 - Xuewei Feng, Chuanpu Fu, Qi Li, Kun Sun, and Ke Xu discovered that the TCP implementation in the Linux kernel did not properly handle IPID assignment. A remote attacker could use this to cause a denial of service or inject forged data. Ke Sun, Alyssa Milburn, Henrique Kawakami, Emma Benoit, Igor Chervatyuk, Lisa Aichele, and Thais Moreira Hamasaki discovered that the Spectre Variant 2 mitigations for AMD processors on Linux were insufficient in some situations. A local attacker could possibly use this to expose sensitive information.
Ubuntu Security Notice 6013-1 - Xuewei Feng, Chuanpu Fu, Qi Li, Kun Sun, and Ke Xu discovered that the TCP implementation in the Linux kernel did not properly handle IPID assignment. A remote attacker could use this to cause a denial of service or inject forged data. Ke Sun, Alyssa Milburn, Henrique Kawakami, Emma Benoit, Igor Chervatyuk, Lisa Aichele, and Thais Moreira Hamasaki discovered that the Spectre Variant 2 mitigations for AMD processors on Linux were insufficient in some situations. A local attacker could possibly use this to expose sensitive information.
Ubuntu Security Notice 6001-1 - Xuewei Feng, Chuanpu Fu, Qi Li, Kun Sun, and Ke Xu discovered that the TCP implementation in the Linux kernel did not properly handle IPID assignment. A remote attacker could use this to cause a denial of service or inject forged data. Ke Sun, Alyssa Milburn, Henrique Kawakami, Emma Benoit, Igor Chervatyuk, Lisa Aichele, and Thais Moreira Hamasaki discovered that the Spectre Variant 2 mitigations for AMD processors on Linux were insufficient in some situations. A local attacker could possibly use this to expose sensitive information.