| Message ID | 20230724124057.12975-1-oneukum@suse.com |
|---|---|
| State | New |
| Headers | show |
| Series | USB: hub: make sure stale buffers are not enumerated | expand |
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index a739403a9e45..9772716925c3 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4873,7 +4873,8 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1, } #define GET_DESCRIPTOR_BUFSIZE 64 - buf = kmalloc(GET_DESCRIPTOR_BUFSIZE, GFP_NOIO); + /* zeroed so we don't operate on a stale buffer on errors */ + buf = kzalloc(GET_DESCRIPTOR_BUFSIZE, GFP_NOIO); if (!buf) { retval = -ENOMEM; continue;
Quoting Alan Stern on why we cannot just check errors: The operation carried out here is deliberately unsafe (for full-speed devices). It is made before we know the actual maxpacket size for ep0, and as a result it might return an error code even when it works okay. This shouldn't happen, but a lot of USB hardware is unreliable. Therefore we must not ignore the result merely because r < 0. If we do that, the kernel might stop working with some devices. He is absolutely right. However, we must make sure that in case we read nothing or a short answer, the buffer contains nothing that can be misinterpreted as a valid answer. So we have to zero it before we use it for IO. Reported-by: liulongfang <liulongfang@huawei.com> Signed-off-by: Oliver Neukum <oneukum@suse.com> --- drivers/usb/core/hub.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)