Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1021151ybp; Fri, 11 Oct 2019 07:55:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqxO1avjbO8dVdgMqJvs4xrIIeDq1lVgUXLwSftlA1pPPVxQhW+vOxALMhegsUU/aMK5Hmdq X-Received: by 2002:a17:906:448e:: with SMTP id y14mr14500738ejo.136.1570805700040; Fri, 11 Oct 2019 07:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570805700; cv=none; d=google.com; s=arc-20160816; b=0uC8pmFrAwi1ugUgDMrAO4fvh5ZFtkD1+9ElJcww1DJgeBQbRjLJCRmRYutmF9CI9I CtU0TDgwAjYZbOgxme7lPiuPxaUhIoV3GG+VPwjCYHovVMmzkvngLA5zehFg2BRUG1Ds x10XTwvVS7G3Ba/Z7dFMUYp1lH8vKam/LB7h61uG75JICMNLJgvyWvFzJgjEHlye+OA/ FF3vlcXzjjWtF9j2XuCDp0YwWWY4FcLqY7Kp/pk5+3FPyONn5+50BDV07iqNfFC8izgg BtX3khGPIEqYiDQj15IH1UuxFA3nOnaE3ji73Dy1JG0ACF4UCrw38K76XF4RKmfOUpgr 2aNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=kvEa8rU4Erm2mA7KA/zKzD1nuCi0o8duCxnoqM4Its8=; b=vemNPGigUhefYOynNIMI1SsmIMajzn22EXW/dpfEN5/nv8LoJGnnC2hjInWZm+DGrV 2tATZ8sddSc5Zo7TwOweDBMfOE5jRNKbJ52PDrT6Fad4KoAfyH/baSI9X7ar8YY3NBHt sDDHK9XVoFAet1ymYJRY/cqe3bMr/2pX62z66jDdyvmW5DME2cN/fjZdkQwDYo8k2pTZ gWP66sL5X9oyBMtNwnTVdjN5eX0UAYirZlrqUFX4BmBtwjM+5E2MjafeJtkm65gSGlIY DRVM9TeQ5JJaTf3i6b3EoNCLp8VeoGDUysQVnWzffbWaQz2w2sGSwSkYrZFwn9wkY4Dc xQvA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e22si5946179ejm.72.2019.10.11.07.54.37; Fri, 11 Oct 2019 07:55:00 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727721AbfJKOxt (ORCPT + 99 others); Fri, 11 Oct 2019 10:53:49 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:41924 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726332AbfJKOxs (ORCPT ); Fri, 11 Oct 2019 10:53:48 -0400 Received: (qmail 3769 invoked by uid 2102); 11 Oct 2019 10:53:47 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Oct 2019 10:53:47 -0400 Date: Fri, 11 Oct 2019 10:53:47 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Andrey Konovalov cc: Jaskaran Singh , syzbot , Alexander Potapenko , Greg Kroah-Hartman , LKML , USB list , syzkaller-bugs , Subject: Re: KMSAN: uninit-value in alauda_check_media In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 Oct 2019, Andrey Konovalov wrote: > On Fri, Oct 11, 2019 at 4:08 PM Alan Stern wrote: > > Now yes, it's true that defining status as an array on the stack is > > also a bug, since USB transfer buffers are not allowed to be stack > > variables. > > Hi Alan, > > I'm curious, what is the reason for disallowing that? Should we try to > somehow detect such cases automatically? Transfer buffers are read and written by DMA. On systems that don't have cache-coherent DMA controllers, it is essential that the CPU does not access any cache line involved in a DMA transfer while the transfer is in progress. Otherwise the data in the cache would be different from the data in the buffer, leading to corruption. (In theory it would be okay for the CPU to read (not write!) a cache line assigned to a buffer for a DMA write (not read!) transfer. But even doing that isn't really a good idea.) (Also, this isn't an issue for x86 architectures, because x86 has cache-coherent DMA. But it is an issue on other architectures.) In practice, this means transfer buffers have to be allocated by something like kmalloc, so that they occupies their own separate set of cache lines. Buffers on the stack obviously don't satisfy this requirement. At some point there was a discussion about automatically detecting when on-stack (or otherwise invalid) buffers are used for DMA transfers. I don't recall what the outcome was. Alan Stern