Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ