From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34CB8C2BB1D for ; Tue, 14 Apr 2020 20:45:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D61F52064A for ; Tue, 14 Apr 2020 20:45:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D61F52064A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 41A718E0003; Tue, 14 Apr 2020 16:45:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CBD78E0001; Tue, 14 Apr 2020 16:45:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E09D8E0003; Tue, 14 Apr 2020 16:45:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 15A878E0001 for ; Tue, 14 Apr 2020 16:45:41 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CD39D180AD80F for ; Tue, 14 Apr 2020 20:45:40 +0000 (UTC) X-FDA: 76707641640.23.hair48_146d7ef414659 X-HE-Tag: hair48_146d7ef414659 X-Filterd-Recvd-Size: 4429 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by imf50.hostedemail.com (Postfix) with SMTP for ; Tue, 14 Apr 2020 20:45:39 +0000 (UTC) Received: (qmail 6693 invoked by uid 500); 14 Apr 2020 16:45:38 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Apr 2020 16:45:38 -0400 Date: Tue, 14 Apr 2020 16:45:38 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Andrey Konovalov cc: Alexander Potapenko , Andrew Morton , Greg Kroah-Hartman , Eric Dumazet , Wolfram Sang , Petr Mladek , Vegard Nossum , Dmitry Vyukov , Marco Elver , Linux Memory Management List , Alexander Viro , Andreas Dilger , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , Christoph Hellwig , "Darrick J. Wong" , "David S. Miller" , Dmitry Torokhov , Eric Biggers , Eric Van Hensbergen , Harry Wentland , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jason Wang , Jens Axboe , Marek Szyprowski , Mark Rutland , "Martin K. Petersen" , Martin Schwidefsky , Matthew Wilcox , "Michael S . Tsirkin" , Michal Hocko , Michal Simek , Qian Cai , Randy Dunlap , Robin Murphy , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , Theodore Ts'o , Thomas Gleixner , Vasily Gorbik Subject: Re: [PATCH v5 20/38] kmsan: handle memory sent to/from USB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 14 Apr 2020, Andrey Konovalov wrote: > On Tue, Apr 14, 2020 at 5:50 PM Alan Stern wrote: > > This has got a couple of problems. > > > > Firstly, for control URBs it doesn't check urb->setup_packet, which > > should always be initialized regardless of the direction because it > > always gets sent to the device. > > Ah, yes, we actually had an info-leak report for a bug in the sound > subsystem that was leaking data this way, which was misattributed to > raw-gadget. This makes sense to add and seems quite easy. > > > Secondly, some URBs use scatter-gather transfers, and they don't always > > store the buffer address in urb->transfer_buffer (indeed, sometimes the > > buffer is located outside of the kernel's address map). Instead they > > use urb->sg and urb->num_sgs. To get an idea for how it all works, > > look at usb_hcd_map_urb_for_dma() in hcd.c. > > Oh, this is something we need to look into. > > > Thirdly, the information we get back from the device doesn't always > > cover the entire transfer buffer; sometimes the device sends less data > > than we asked for. Perhaps you don't care very much about this case. > > So you mean that we should look at actual_length rather than > transfer_buffer_length when initializing memory that comes from the > device? Yes, in theory. Isochronous transfers are difficult, because the data doesn't have to be contiguous in memory. If you want to handle them properly, you have to loop through the entries in the urb->iso_frame_desc[] array and treat them individually. Alan Stern