Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp664762pxj; Fri, 14 May 2021 12:30:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxv/7WTLlmmeD4/twOgcFGysOgmCqYaTSrCOCWp5XYXYjVgBq7JfySWPOXO1Wy22prVLQkZ X-Received: by 2002:a05:6402:8da:: with SMTP id d26mr58100630edz.161.1621020646914; Fri, 14 May 2021 12:30:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621020646; cv=none; d=google.com; s=arc-20160816; b=WfqJGqjcSZXSyRzkH7whP+gLaTppVy6hs/HwN4Zbg0CbIQTnZvlin8uCXQaRMMg2R2 Z8P9e3cxBDG6Y8rdcKsPmMwppe1MSIDQFBU0Tmh7ZiPyF96E2naSp1rgTOS2QRnvJAGS fl49kC6oiiGhabPJD4BKp6fU2lYDgCU0IwSVFjXTv1wSbtNSfkQQxY8tt0YydIViU9DE RKB1N10l8LbhMF3pi02rVz7aKAaE4mUDHfm5x1+7rRUfoG68IGtsxdLE850LBRhybjSC fTjguawTqIsLcg7AQhBV+L2OCJq7aRgWxAHIfgM3iuhADBQEoTDilN73wt4odoidizAe 57Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=U4GSgalQBTViCTkE4g2IaXKFxl9uvHgmV2+gLuTXjeE=; b=kVGL4A05Ne6v+cYouveVf7LLSGc6UJXvQ2KvvbBKwhXr48/8var+WG5h93FEtu6N94 PDgn3S2oSyjE6n/E8UmHv1PtldZCW2OwyIcAzoDRYSK1nZdVZjQ+KyLUklis0MPQuovA iVRwY6Disdcbx93//MljXK8YTVZfAf2xd037x+8JRN+LL554wmQXf4199WRWGuoQIT8n vKa1wzyuHk0Qpw5OtWNKmFt4/pcVJJQUSl+y0VYS8GVKXQ/dllw6vMmHOUiSSOWlc8+/ cw+cdN3WVZQz7hE8JVc/ySe1qAKbcc1wO37kXA3TQYGb+7v+ebzg+pgFMUUje+omLQVA IIzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si7225578ejj.534.2021.05.14.12.30.23; Fri, 14 May 2021 12:30:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234848AbhENPeV (ORCPT + 99 others); Fri, 14 May 2021 11:34:21 -0400 Received: from netrider.rowland.org ([192.131.102.5]:39513 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S234862AbhENPeG (ORCPT ); Fri, 14 May 2021 11:34:06 -0400 Received: (qmail 1009388 invoked by uid 1000); 14 May 2021 11:32:53 -0400 Date: Fri, 14 May 2021 11:32:53 -0400 From: Alan Stern To: Hayes Wang Cc: Greg KH , syzbot , "davem@davemloft.net" , "kuba@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , "netdev@vger.kernel.org" , "syzkaller-bugs@googlegroups.com" , nic_swsd Subject: Re: [syzbot] WARNING in rtl8152_probe Message-ID: <20210514153253.GA1007561@rowland.harvard.edu> References: <0000000000009df1b605c21ecca8@google.com> <7de0296584334229917504da50a0ac38@realtek.com> <20210513142552.GA967812@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 14, 2021 at 07:50:19AM +0000, Hayes Wang wrote: > Greg KH > > Sent: Friday, May 14, 2021 2:49 PM > [...] > > Because people can create "bad" devices and plug them into a system > > which causes the driver to load and then potentially crash the system or > > do other bad things. > > > > USB drivers now need to be able to handle "malicious" devices, it's been > > that way for many years now. > > My question is that even I check whole the USB descriptor, the malicious > devices could duplicate it easily to pass my checks. That is, I could add a > lot of checks, but it still doesn't prevent malicious devices. Is this meaningful? The real motivation here, which nobody has mentioned explicitly yet, is that the driver needs to be careful enough that it won't crash no matter what bizarre, malfunctioning, or malicious device is attached. Even if a device isn't malicious, if it is buggy, broken, or malfunctioning in some way then it can present input that a normal device would never generate. If the driver isn't prepared to handle this unusual input, it may crash. That is specifically what we want to avoid. So if a peculiar emulated device created by syzbot is capable of crashing the driver, then somewhere there is a bug which needs to be fixed. It's true that fixing all these bugs might not protect against a malicious device which deliberately behaves in an apparently reasonable manner. But it does reduce the attack surface. Alan Stern