Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5906726imm; Mon, 27 Aug 2018 06:29:40 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaU5EzOuaxD/MnlFMz1cGEpl/9o9dkYXH9a1tButcQB3qSj+3hgoGU6xkbJHkGZ0hldf0Vc X-Received: by 2002:a17:902:710c:: with SMTP id a12-v6mr13314901pll.28.1535376580074; Mon, 27 Aug 2018 06:29:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535376580; cv=none; d=google.com; s=arc-20160816; b=nxaRGZW+DZIm1+R4mlZS8Rep2p6cKYXjwKa8kUxv/lgye2vBiFzc/Q2N13J9zqPkKH eNpR9r4JeW7gMaFxYuMOms5nW2rhqozJFL0O9mwNpTeYgSXMNg5/FAl2rA68Ayw4Wb80 Z4Ouk0S3k6ZDbOk0FWkylQkH4sUYjn3aJnX9qE3pvJrLRcqurx/66vlfNWPC810mShns FCPlbM0AKFdvFDm9fsBmxFGIuZUW3R+TiKFfxIxR2JpwIH8+Nx79Hfgk1VRHL2/xI9om uXQROGkyE2DtrE55keaoWDIjTO0y1/P62hz0nV3qNZ1N41GKWOvRKL4xxWBgT8FJE3NT Z/Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=STeny4papD9J8QVXm0sMEfiIam3kpb9dFMOWyPKtg/c=; b=loHZhXMbh1YTGRQsF2xxtvw3C1AJ3mLQ4OhE+Txu5n1fso0yFR9+gJ9yg0seLX8Aeu glUwYuHIoxKO9B2vvMNAE2Xt22yuGns36P//vuL1Mu/Clus3na5GiyjpFkCoyxXTRHm7 XB+GnPMmo3ovZBANJnATMucvCuYHSWtnfIv07IHdn80OEVWAnzAScxxS4GqdwsumzT45 9NoZX2fGY0hPo4u8nFOtADCv3418bI0Q5ib9p/Ga4wbKbTuhJUNnhM4sHVaeVQ6faeew TaPM7WX7v5+wPo3APGF0+Fyug3hDrUz6ax5LWXDtm3+nwfK1GRYVO9W3Y3dXUXaDAkbs 9HDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=VRhSayuR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 89-v6si14460951pla.310.2018.08.27.06.29.23; Mon, 27 Aug 2018 06:29:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=VRhSayuR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727113AbeH0RO5 (ORCPT + 99 others); Mon, 27 Aug 2018 13:14:57 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:36908 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726905AbeH0RO5 (ORCPT ); Mon, 27 Aug 2018 13:14:57 -0400 Received: by mail-lj1-f195.google.com with SMTP id v9-v6so12352681ljk.4; Mon, 27 Aug 2018 06:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=STeny4papD9J8QVXm0sMEfiIam3kpb9dFMOWyPKtg/c=; b=VRhSayuRVHgC4kXYIC9nr2l7cdjTd+0sO0yvs3cAyqe0DXXJxdt/kNT86FWdWhtDCt vsYFowkmdYhZg/wAhcpob3oJrAEmnYcORNwRMkgG1fz+Ba2fAWVdRQ049hA3cTbkGcwy wH4rGyYZMcligGheKqLYY/ZCzmRdj92FoYPvul97yBl7PAftU8Sa08vdGhyO+Z4VlqAE sEUmvzQBh1clIpeSRmeu6TjxvxFHZFdIoeeEI6wz6EhAlyYpgwqc8wKL5pFurrTuO+lD O80KQOz6/Fgi8cVrkRJhXBpT6RVyelyIUlXTwuyFvsBBNKHyYQH+88TKneG4yRJ8+cD2 Cb8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=STeny4papD9J8QVXm0sMEfiIam3kpb9dFMOWyPKtg/c=; b=Xfz9XJqjysEi6K12blwCSVgGvnB6EuVHEunfFvW4dlkaZAHRtluy/2PvPXGuSLLPRH YLfx295Cd6/9nEFMPFETK2/EHORL7BMl/Du2OYl0S6xjGhq1omWE/v0Lmwb7lhuB26QG no8wETb8Q2nbH83cniFkVsdi71NRZEEIhUqTsi29x7KEP9h4bOdnpr35hPSHIij6Kbn6 2jUN/hNUcJy8XdOuGhEr/Bof1FqUDIeIoGKS1F40mNg9UdW++sY0A0KB8BhHxS0x3QIr t6ZkoLhLB9vo/CUyyWTwdJ8ZOlETlwGmgR7X2e8jl0vooi4Dd5RHRY2ENgERSlEyUBOd lGlg== X-Gm-Message-State: APzg51AFDYlWmeBI34q2NkZBKf9G+0y5aaJDPooYT49/0VfENCTlhRXl awNey0Ru6kU9icUB80binIM= X-Received: by 2002:a2e:2d2:: with SMTP id y79-v6mr8318389lje.100.1535376496136; Mon, 27 Aug 2018 06:28:16 -0700 (PDT) Received: from xi.terra (c-74bee655.07-184-6d6c6d4.bbcust.telenor.se. [85.230.190.116]) by smtp.gmail.com with ESMTPSA id v62-v6sm2859287lfa.51.2018.08.27.06.28.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 06:28:15 -0700 (PDT) Received: from johan by xi.terra with local (Exim 4.91) (envelope-from ) id 1fuHZ1-0001eP-2m; Mon, 27 Aug 2018 15:28:15 +0200 Date: Mon, 27 Aug 2018 15:28:15 +0200 From: Johan Hovold To: Romain Izard Cc: Greg Kroah-Hartman , Johan Hovold , linux-usb@vger.kernel.org, LKML , stable , =?iso-8859-1?Q?Bj=F8rn?= Mork , Lars Melin Subject: Re: [PATCH] option: Do not try to bind to ADB interfaces Message-ID: <20180827132815.GD14967@localhost> References: <20180723140220.7166-1-romain.izard.pro@gmail.com> <20180723140801.GA4835@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 23, 2018 at 06:45:22PM +0200, Romain Izard wrote: > 2018-07-23 16:08 GMT+02:00 Greg Kroah-Hartman : > > On Mon, Jul 23, 2018 at 04:02:20PM +0200, Romain Izard wrote: > >> Some modems now use the Android Debug Bridge to provide a debugging > >> interface, and some phones can also export serial ports managed by the > >> "option" driver. > >> > >> The ADB daemon running in userspace tries to use USB interfaces with > >> bDeviceClass=0xFF, bDeviceSubClass=0x42, bDeviceProtocol=1 > >> > >> Prevent the option driver from binding to those interfaces, as they > >> will not be serial ports. > >> > >> This can fix issues like: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781256 > >> > >> Signed-off-by: Romain Izard > >> Cc: stable > >> --- > >> drivers/usb/serial/option.c | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c > >> index 664e61f16b6a..f98943a57ff0 100644 > >> --- a/drivers/usb/serial/option.c > >> +++ b/drivers/usb/serial/option.c > >> @@ -1987,6 +1987,12 @@ static int option_probe(struct usb_serial *serial, > >> if (iface_desc->bInterfaceClass == USB_CLASS_MASS_STORAGE) > >> return -ENODEV; > >> > >> + /* Do not bind Android Debug Bridge interfaces */ > >> + if (iface_desc->bInterfaceClass == USB_CLASS_VENDOR_SPEC && > >> + iface_desc->bInterfaceSubClass == 0x42 && > >> + iface_desc->bInterfaceProtocol == 1) > >> + return -ENODEV; > > > > Shouldn't you also check the vendor/product id as well? Otherwise this > > has the potential to match random devices that are not really adb > > devices. > > The only random devices are those that already match with the option driver, > either with the whole device or the whole reserved class. It reduces the > amount of potentially affected devices. > > Among those, I do not expect any of them to use 0xff,0x42,0x01 for a > serial port. But if it occurred, it would be necessary to revert this change as > no userspace hack would allow to rebind the interface. Yeah, but by that time we may have added (or enabled) devices that rely on this general rule so we'd need to start adding exceptions to this negative matching rule instead... > As this is only an intuition, please discard this patch if you have any doubt > about this. Bj?rn also suggested that we at least consider adding a rule like this a few months ago (when I changed the blacklist implementation). I just never got around to look into it. It would allow for simpler device-id entries, at least when ADB is the only blacklisted interface, and may enable ADB for some older entries. On the other hand, interface class 0xff is indeed supposed to be vendor specific as Lars and Greg pointed out, and with status quo we don't cause any regressions. If ADB isn't currently available for some device due to option binding to that interface, we'll just blacklist it as soon we get a report. So personally I'm not sure it's worth it, but I don't have a strong opinion on the matter either. Johan