[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOs+rJVMeTCh8J38eKABrf7WVd=HCv=q0doYkURsgh4bC6MsTw@mail.gmail.com>
Date: Tue, 19 Apr 2016 10:09:32 +0100
From: Ignat Korchagin <ignat.korchagin@...il.com>
To: Greg KH <greg@...ah.com>
Cc: Marcus Meissner <meissner@...e.de>, OSS Security List <oss-security@...ts.openwall.com>,
security@...nel.org
Subject: Re: CVE Request: Linux kernel: remote buffer overflow in usbip
Hello,
Yes, I contacted cve-assign@...re.org and they provided me with the
following number:
CVE-2016-3955
Regards,
Ignat
2016-04-19 9:35 GMT+01:00 Greg KH <greg@...ah.com>:
> On Tue, Apr 19, 2016 at 10:06:43AM +0200, Marcus Meissner wrote:
>> Hi,
>>
>> https://github.com/torvalds/linux/commit/b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb
>>
>> commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb
>> Author: Ignat Korchagin <ignat.korchagin@...il.com>
>> Date: Thu Mar 17 18:00:29 2016 +0000
>>
>> USB: usbip: fix potential out-of-bounds write
>>
>> Fix potential out-of-bounds write to urb->transfer_buffer
>> usbip handles network communication directly in the kernel. When receiving a
>> packet from its peer, usbip code parses headers according to protocol. As
>> part of this parsing urb->actual_length is filled. Since the input for
>> urb->actual_length comes from the network, it should be treated as untrusted.
>> Any entity controlling the network may put any value in the input and the
>> preallocated urb->transfer_buffer may not be large enough to hold the data.
>> Thus, the malicious entity is able to write arbitrary data to kernel memory.
>>
>> Signed-off-by: Ignat Korchagin <ignat.korchagin@...il.com>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>
>> diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
>> index facaaf0..e40da77 100644
>> --- a/drivers/usb/usbip/usbip_common.c
>> +++ b/drivers/usb/usbip/usbip_common.c
>> @@ -741,6 +741,17 @@ int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb)
>> if (!(size > 0))
>> return 0;
>>
>> + if (size > urb->transfer_buffer_length) {
>> + /* should not happen, probably malicious packet */
>> + if (ud->side == USBIP_STUB) {
>> + usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
>> + return 0;
>> + } else {
>> + usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
>> + return -EPIPE;
>> + }
>> + }
>> +
>> ret = usbip_recv(ud->tcp_socket, urb->transfer_buffer, size);
>> if (ret != size) {
>> dev_err(&urb->dev->dev, "recv xbuf, %d\n", ret);
>>
>> Our USB developer confirms:
>> https://bugzilla.suse.com/show_bug.cgi?id=975945
>> |The vulnerability is true. If an attacker can get a malicious package
>> |into the connection the kernel will accept all of the data in that
>> |package whether it fits into the buffer or not.
>> |You can scribble about 1k into RAM, albeit at an unpredictable location.
>
> I think Ignat already asked for a CVE for this through some other
> channel, and was going to announce it in some manner.
>
> Ignat, did you do that?
>
> thanks,
>
> greg k-h
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
