Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754280AbbDMQA2 (ORCPT ); Mon, 13 Apr 2015 12:00:28 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:47698 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753847AbbDMQAZ (ORCPT ); Mon, 13 Apr 2015 12:00:25 -0400 Date: Mon, 13 Apr 2015 18:02:27 +0200 From: Quentin Casasnovas To: Adam Lee Cc: Quentin Casasnovas , lkml , linux-usb , Phil Turnbull , Oliver Neukum , Greg Kroah-Hartman Subject: Re: [PATCH] cdc-acm: prevent infinite loop when parsing CDC headers. Message-ID: <20150413160227.GF12442@chrystal.uk.oracle.com> References: <1428938644-19942-1-git-send-email-quentin.casasnovas@oracle.com> <20150413154827.GA2458@adam-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150413154827.GA2458@adam-laptop> User-Agent: Mutt/1.5.22 (2013-10-16) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1582 Lines: 40 On Mon, Apr 13, 2015 at 11:48:27PM +0800, Adam Lee wrote: > On Mon, Apr 13, 2015 at 05:24:04PM +0200, Quentin Casasnovas wrote: > > Phil and I found out a problem with commit: > > > > 7e860a6e ("cdc-acm: add sanity checks") > > > > It added some sanity checks to ignore potential garbage in CDC headers but > > also introduced a potential infinite loop. This can happen at the first > > loop iteration (elength = 0 in that case) if the description isn't a > > DT_CS_INTERFACE or later if 'buffer[0]' is zero. > > > > It should also be noted that the wrong length was being added to 'buffer' > > in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was > > assigned after that check in the loop. > > > > A specially crafted USB device could be used to trigger this infinite loop. > > Yes, "elength = buffer[0]" should be moved to the front of > USB_DT_CS_INTERFACE check, ACK this part. > > But I don't know in what case the buffer[0] could be zero, if it > happens, better to set elength 1 then goto next_desc? (I'm not a > maintainer, pleas also consider others' opinion) > Hi Adam, I'm happy to change it as you suggest, though at that point we'll probably be trying to parse garbage anyway. If nobody had a different opinion in the meantime, I'll send a v2 tomorrow. Thanks for the review :) Quentin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/