Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp178463yba; Fri, 12 Apr 2019 01:07:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqwhJ68TVTYgzJKb17ekUoVyi7Oorx66YTXtGslOtw4+yUlRLpMKOn5emMzJxHjvd4hVNxLO X-Received: by 2002:a63:2747:: with SMTP id n68mr10368257pgn.317.1555056442716; Fri, 12 Apr 2019 01:07:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555056442; cv=none; d=google.com; s=arc-20160816; b=eIdv2IS11teMQv5xVLiBj6Ewb0KYa0a26oIYGHSZBMpdDk9Kzt+nnkN0b10Bnhv3kV ywwA/czY+6+v/YHOcSevfxtmud1XNvIOyFNIbWWy+EEJWFKsHE3/ZKbhEc8N0damN/4O KVg3EYsHSHw5KzwTccHliI2a85uTt/ALx4cOrTLXrB1p3XciaoP+VuXkf5yGWM20n7Xn 5CKMu8/mn+O82LBWKWM8QPUpwvv7jcaD7r3f+Xa8lkeTymyCTvrp0SjhQq6LDCuLoiqa NRYnE51j6ZSysJF285eb2V02d+58b3KnhXti7HFxl7xb+oasTX04gWimJLgP5e/20q5o u3zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:organization :subject:cc:to:from:dkim-signature; bh=TEkdjUFncQpPGr5cjnaKDc1jJA03Oku+3cZNXWXIdlQ=; b=KdLvvuNjXTa6JD/hGmniE+ZAC+ayZzrKykiZzCv7LZYODOLPB/agggY9JDNA1V7BsR mViJW7M066QOA8Gv1LCdfc/OrSRO+ZxdrNV3jCbKZZgiBeVzSBFdZHxgxB/Dcb9wpJmV cYwzwcw3CS8NRhS6RiGVSN4/Wj0pSb+HbljQrm92VB24oQyzKBRpgpNvUG+0BTGZsZbs KEkuUmkEQK7I/pFw8dSZDM0nczgPwSk4r4IeTt4zkzzfdVxGCPzTQ28rwLdyjOo6qBoO R0SsKTDklmQky0Fbh30e3bvszds5D9qUg94mP8tna5g69uXH4YciGN/KFRGjI1LGyXYe LgFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mork.no header.s=b header.b=ozdscDFP; 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=pass (p=NONE sp=NONE dis=NONE) header.from=mork.no Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e7si36500942pfc.152.2019.04.12.01.07.06; Fri, 12 Apr 2019 01:07:22 -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=pass header.i=@mork.no header.s=b header.b=ozdscDFP; 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=pass (p=NONE sp=NONE dis=NONE) header.from=mork.no Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727233AbfDLIEw (ORCPT + 99 others); Fri, 12 Apr 2019 04:04:52 -0400 Received: from canardo.mork.no ([148.122.252.1]:56899 "EHLO canardo.mork.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726024AbfDLIEv (ORCPT ); Fri, 12 Apr 2019 04:04:51 -0400 Received: from miraculix.mork.no ([IPv6:2a02:2121:34e:7a0c:4cff:dff:fef6:bcb]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id x3C84Ebf014007 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Apr 2019 10:04:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1555056256; bh=TEkdjUFncQpPGr5cjnaKDc1jJA03Oku+3cZNXWXIdlQ=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=ozdscDFPm0M7yNoNVmhDnMc9RQ5Am6yBi10OnL6WJNVDgnBX39PGx2zDwRYhXUnS+ 8XPRgRphsnOfRPZ8KjgNEYrgOUYYb3Q2IfDo7AsH30bblIlkU5zrmq4EF8IQm/qBak cb8sXnzkLR5+fc45UWtlrq5YluWkB5IQSejuqtQo= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1hErAP-000557-Jz; Fri, 12 Apr 2019 10:04:09 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Young Xiao <92siuyang@gmail.com> Cc: kbuild-all@01.org, linux-usb@vger.kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, greg@kroah.com, mchehab@kernel.org, keescook@chromium.org, hans.verkuil@cisco.com, Young Xiao Subject: Re: [PATCH] USB: s2255 & stkwebcam: fix oops with malicious USB descriptors Organization: m References: <1555036767-31170-1-git-send-email-92siuyang@gmail.com> Date: Fri, 12 Apr 2019 10:04:09 +0200 In-Reply-To: <1555036767-31170-1-git-send-email-92siuyang@gmail.com> (Young Xiao's message of "Fri, 12 Apr 2019 10:39:27 +0800") Message-ID: <878swf645i.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.100.3 at canardo X-Virus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Please mark updated patches with a version number or some other indication that it replaces a previous patch. Including a summary of changes is also normal. And speaking of normal: We do build test our patches, don't we? Young Xiao <92siuyang@gmail.com> writes: > From: Young Xiao > > The driver expects at least one valid endpoint. If given > malicious descriptors that specify 0 for the number of endpoints, > it will crash in the probe function. No, it won't. Did you test this? Can you provide the oops? This is perfectly fine as it is: dev =3D kzalloc(sizeof(struct s2255_dev), GFP_KERNEL); .. for (i =3D 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint =3D &iface_desc->endpoint[i].desc; if (!dev->read_endpoint && usb_endpoint_is_bulk_in(endpoint)) { /* we found the bulk in endpoint */ dev->read_endpoint =3D endpoint->bEndpointAddress; } } if (!dev->read_endpoint) { dev_err(&interface->dev, "Could not find bulk-in endpoint\n"); goto errorEP; } > drivers/media/usb/stkwebcam/stk-webcam.c | 6 ++++++ I didn't bother looking at this driver to see if your patch there makes more sense. That is your home work now. Please explain why you believe it is. An actual oops would be good. Yes, and I do have some objections to this whole "protect against malicious devices". How do you intend to protect against a USB device disguising itself as a keyboard or ethernet adapater or whatever? Allowing potentionally malicious devices is crazy enough for USB, and it gets completely wacko when people start talking about it in the context of firewire or PCIe Fixing bugs in drivers is fine. But it won't make any difference wrt security if you connect malicious devices to your system. Don't do that if you want a secure system. Allocating CVE numbers to arbitrary driver bugs is just adding noise. This noise makes it harder for sysadmins and others to to notice the really important problems. No one will care anymore if every kernel release fixes thousands of CVEs. Which is pretty close to the truth if you start allocating CVE numbers to any bug with a security impact. Bj=C3=B8rn