From patchwork Thu Apr 21 14:19:17 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Henriques X-Patchwork-Id: 613128 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3qrLVP70zlz9sds; Fri, 22 Apr 2016 00:19:41 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.76) (envelope-from ) id 1atFSE-0000uR-As; Thu, 21 Apr 2016 14:19:38 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1atFRx-0000rD-RU for kernel-team@lists.ubuntu.com; Thu, 21 Apr 2016 14:19:21 +0000 Received: from 1.general.henrix.uk.vpn ([10.172.192.212] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1atFRx-0007cy-ET; Thu, 21 Apr 2016 14:19:21 +0000 From: Luis Henriques To: kernel-team@lists.ubuntu.com Subject: [CVE-2016-3955][Precise] USB: usbip: fix potential out-of-bounds write Date: Thu, 21 Apr 2016 15:19:17 +0100 Message-Id: <1461248359-25056-2-git-send-email-luis.henriques@canonical.com> In-Reply-To: <1461248359-25056-1-git-send-email-luis.henriques@canonical.com> References: <1461248359-25056-1-git-send-email-luis.henriques@canonical.com> Cc: kamal@canonical.com X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.14 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: kernel-team-bounces@lists.ubuntu.com From: Ignat Korchagin 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 Signed-off-by: Greg Kroah-Hartman (backported from commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb) [ luis: usbip is still in 'staging' for this kernel version ] CVE-2016-3955 BugLink: https://bugs.launchpad.net/bugs/1572666 Signed-off-by: Luis Henriques --- drivers/staging/usbip/usbip_common.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/staging/usbip/usbip_common.c b/drivers/staging/usbip/usbip_common.c index 194e974051f3..4fbef0c28343 100644 --- a/drivers/staging/usbip/usbip_common.c +++ b/drivers/staging/usbip/usbip_common.c @@ -820,6 +820,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_xmit(0, ud->tcp_socket, (char *)urb->transfer_buffer, size, 0); if (ret != size) {