Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp7418783rwr; Wed, 10 May 2023 08:03:01 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4VKQpJwnop1xLijMhjbZ6NppZy8avifHueJwc02KQduVOBb3A3DDLSGER1Ggy4GcsGLcTk X-Received: by 2002:a05:6870:a683:b0:195:fe38:3b60 with SMTP id i3-20020a056870a68300b00195fe383b60mr5977328oam.25.1683730981203; Wed, 10 May 2023 08:03:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683730981; cv=none; d=google.com; s=arc-20160816; b=YSm+ifCr53EyqOrxSnRlJ6qZvMLDntR8QeANDwZ4BBpRCnSxvP8kB7pVeY/LZIxxUg hF4Vr37uEAgFJdXbkzOvF8994Fckf55jxEK8W7mCo4vzdJq6XRR8+J8Yn6hJwXsETwsk ezeQO7B/HrLZ83PnafG3tecwwMFJOeqWEJ1UFpNL38fMfSPN8i/8Tnn1ELAIeDxyotmC cP6GGIMyyyoI5jfJdR5039z0Tm+j9wnwU11QlkeKHdsldr/i93ZNnVXavM4yPMU/Y4O6 VxI5BjxS9NVVhwqFxvRyln0LaTIopey0P9YKjFhQDwBT6e+s/sBxidWtE45ZtYb2sZEW fxYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=QpqeSXebkxMjm8UKxpRNEJM4CYRIubnRV3k1OInz4R4=; b=flQThCdLWZHleodocMLASn/jubzyPDxxF54HurV9MhxOMIlgqNOYFFW7wn85Fb/knf y6GJD7MQ1+ed3UmcKQr1RckvtPIFwamsDxgTF8KoleHCTWonscBQtsI8uMthC+gZib6s s0MzHSemedRoq2xlGy253GTfWIRsrIwGUUMuvOFBasZ1U4pMIwbceaQoCS2ZH23RV8ic a67MV61CvuTIMArHTLnMKFsd5X5K9iWfTDZc3sx56fxCcLR91jaQNjd40G0Z2ipeSoc+ uNOB4wG6/XZuQ8VrdUov+59Vfi3ZcJx7ZkAyAA5+0M6YE9cuV12741FKTN8xOWqPfB3T jAxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m16-20020a4a3910000000b005472f071485si3414531ooa.51.2023.05.10.08.02.47; Wed, 10 May 2023 08:03:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237361AbjEJOhu (ORCPT + 99 others); Wed, 10 May 2023 10:37:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230100AbjEJOhs (ORCPT ); Wed, 10 May 2023 10:37:48 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 8C6E13593 for ; Wed, 10 May 2023 07:37:46 -0700 (PDT) Received: (qmail 623576 invoked by uid 1000); 10 May 2023 10:37:45 -0400 Date: Wed, 10 May 2023 10:37:45 -0400 From: Alan Stern To: Ruihan Li Cc: linux-mm@kvack.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Pasha Tatashin , David Hildenbrand , Matthew Wilcox , Andrew Morton , Christoph Hellwig , Greg Kroah-Hartman , syzbot+fcf1a817ceb50935ce99@syzkaller.appspotmail.comm, stable@vger.kernel.org Subject: Re: [PATCH 1/4] usb: usbfs: Enforce page requirements for mmap Message-ID: <65ae7b7f-9dea-429f-aca6-2ce4a75b6531@rowland.harvard.edu> References: <20230510085527.57953-1-lrh2000@pku.edu.cn> <20230510085527.57953-2-lrh2000@pku.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230510085527.57953-2-lrh2000@pku.edu.cn> X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 10, 2023 at 04:55:24PM +0800, Ruihan Li wrote: > The current implementation of usbdev_mmap uses usb_alloc_coherent to > allocate memory pages that will later be mapped into the user space. > Meanwhile, usb_alloc_coherent employs three different methods to > allocate memory, as outlined below: > * If hcd->localmem_pool is non-null, it uses gen_pool_dma_alloc to > allocate memory. > * If DMA is not available, it uses kmalloc to allocate memory. > * Otherwise, it uses dma_alloc_coherent. > > However, it should be noted that gen_pool_dma_alloc does not guarantee > that the resulting memory will be page-aligned. Furthermore, trying to > map slab pages (i.e., memory allocated by kmalloc) into the user space > is not resonable and can lead to problems, such as a type confusion bug > when PAGE_TABLE_CHECK=y [1]. > > To address these issues, this patch introduces hcd_alloc_coherent_pages, > which addresses the above two problems. Specifically, > hcd_alloc_coherent_pages uses gen_pool_dma_alloc_align instead of > gen_pool_dma_alloc to ensure that the memory is page-aligned. To replace > kmalloc, hcd_alloc_coherent_pages directly allocates pages by calling > __get_free_pages. > > Reported-by: syzbot+fcf1a817ceb50935ce99@syzkaller.appspotmail.comm > Closes: https://lore.kernel.org/lkml/000000000000258e5e05fae79fc1@google.com/ [1] > Cc: stable@vger.kernel.org > Signed-off-by: Ruihan Li > --- I'm never quite sure about when it makes sense to complain about stylistic issues. Nevertheless, I'm going to do so here... > drivers/usb/core/buffer.c | 41 +++++++++++++++++++++++++++++++++++++++ > drivers/usb/core/devio.c | 9 +++++---- > include/linux/usb/hcd.h | 5 +++++ > 3 files changed, 51 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c > index fbb087b72..6010ef9f5 100644 > --- a/drivers/usb/core/buffer.c > +++ b/drivers/usb/core/buffer.c > @@ -172,3 +172,44 @@ void hcd_buffer_free( > } > dma_free_coherent(hcd->self.sysdev, size, addr, dma); > } > + > +void *hcd_buffer_alloc_pages(struct usb_hcd *hcd, size_t size, > + gfp_t mem_flags, dma_addr_t *dma) > +{ > + if (size == 0) > + return NULL; > + > + if (hcd->localmem_pool) > + return gen_pool_dma_alloc_align(hcd->localmem_pool, > + size, dma, PAGE_SIZE); C isn't Lisp. Expressions in C are not based entirely around parentheses, and it's not necessary to align our code based on the parenthesized sub-expressions to avoid hopelessly confusing the reader. The style used in this file (and many other places in the USB core) is to indent continuation lines by two tab stops. The same comment applies to all the other continuation lines you added or changed in this patch and in patch 2/4. Alan Stern