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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D131C7EE2C for ; Mon, 8 May 2023 21:37:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCEC26B008C; Mon, 8 May 2023 17:37:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7DB8900003; Mon, 8 May 2023 17:37:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4648900002; Mon, 8 May 2023 17:37:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B5BC56B008C for ; Mon, 8 May 2023 17:37:10 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9220D160156 for ; Mon, 8 May 2023 21:37:10 +0000 (UTC) X-FDA: 80768398620.28.90CCD90 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 4E598C0002 for ; Mon, 8 May 2023 21:37:08 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=OUikKY6m; spf=pass (imf22.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683581828; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SbaY/+tG3VKfkc100DquRuCLrkw9MdA9beMhNTT5GyA=; b=a+PkEQT3ZGIvF6SwkXDmpzQu3zbqJa8a8WGO8/zPFMvshJxZav/owW2DKY7UWc+Y3iiyHo O+Qs5MYS5XQaDZ5gTrqGUEZWzkzxuGrVLfN7o4jZz0LBm+wJG42PwQ2euC4ZDLYwZ/ZD64 iDH6aR6CHm41Egy6u2BemJNKJAikqAw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683581828; a=rsa-sha256; cv=none; b=RexlPR/ivVYmDM4OCT/DQ8JBdUGXwnbZ0aM+jhNYEOi3VR+oO7tGPwrT2VP/5hXqa0TLps V5fqHRuhYLfHOCBFWZtb+pqc6nNu1xGPpcQFuPhbUy15Cqu/goss9Fku3RmQ99Ln985ExY 4DCRWCecww4LzuVJbb3d7E1EC92llGQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=OUikKY6m; spf=pass (imf22.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683581827; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SbaY/+tG3VKfkc100DquRuCLrkw9MdA9beMhNTT5GyA=; b=OUikKY6mQGO/8kDp9S5gI6lO6g9ddWt5xcNMfvbKZWXqEJUwrAn4xaHgP10cdx4bSisX4D 4YGVKY0xnqAEO3vMR6jLPp8gTwVshAYgLrok1lbIb1xWyGxMIKGxt6/R4sKbfzmRGE+S23 AsfsuwOuZ4sW8c0IXMu5T1TagHVl2Bs= Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-588-d-y9dJ9SMr-U_gD7MPZ6PQ-1; Mon, 08 May 2023 17:37:06 -0400 X-MC-Unique: d-y9dJ9SMr-U_gD7MPZ6PQ-1 Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-24e33239357so2801144a91.1 for ; Mon, 08 May 2023 14:37:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683581825; x=1686173825; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SbaY/+tG3VKfkc100DquRuCLrkw9MdA9beMhNTT5GyA=; b=HeqlNgu8AEE6mJKxfwCJdrBrKO9AUzE27avM4uto7roGue+r0IgjkIIq4AYKCEp/mU Wa7hI9FPicMdDZMEAx0te8xb7m9QHxmNN4HRswpfZ0+9lvk5Cl8u86U+iORkN1i6YQ2L zPdnEz1dSLWQZukhJl1Evi2oNYfZBQ4s4latkrW8+e57pxDYtX4RAhctOioX9f/3FMlQ c+4CEuX6h3tWSMl3QsAfNiezw39aWTbqolrSHRHHMQFYccFYtpV8d0xjgu//lg/8OgJE L6ehnPIrF3cIgw8T1BEjU6y6EHB/qhhzK7Q0hwfLGBo35uxbL6a2poHURmDplngaDfrm CH7A== X-Gm-Message-State: AC+VfDxFuD4xPcHlgFnK+Q+P8oCmiJ5T0oHP93ZExEvZo/IQlRz/vuZI SO6GIHA6RaklyFpPY7ccPZebuCrATCHhBkq1xQQmeAGLyB69YsQHqqlTXsZO3ZzNVY7Tj7TvdlX 2/3hn8G0hOuo= X-Received: by 2002:a17:90b:85:b0:24e:4350:cb50 with SMTP id bb5-20020a17090b008500b0024e4350cb50mr11893375pjb.29.1683581824918; Mon, 08 May 2023 14:37:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7nKf1qYn8A5U44GBKxCnO/4AvQjaPfLG0Rt4rAZhAHdTrR5txTZCZtvxSUeejYPDf00CLB0Q== X-Received: by 2002:a17:90b:85:b0:24e:4350:cb50 with SMTP id bb5-20020a17090b008500b0024e4350cb50mr11893353pjb.29.1683581824527; Mon, 08 May 2023 14:37:04 -0700 (PDT) Received: from ?IPV6:2001:4958:15a0:30:5835:5bd3:f0c8:e5ef? ([2001:4958:15a0:30:5835:5bd3:f0c8:e5ef]) by smtp.gmail.com with ESMTPSA id m187-20020a6326c4000000b00524dde7231dsm6819401pgm.9.2023.05.08.14.37.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 May 2023 14:37:04 -0700 (PDT) Message-ID: <8019cf35-e631-0252-0d38-d2454f5f0e11@redhat.com> Date: Mon, 8 May 2023 23:37:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: usbdev_mmap causes type confusion in page_table_check To: Pasha Tatashin , Ruihan Li Cc: syzbot+fcf1a817ceb50935ce99@syzkaller.appspotmail.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, syzkaller-bugs@googlegroups.com, Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka References: <000000000000258e5e05fae79fc1@google.com> <20230507135844.1231056-1-lrh2000@pku.edu.cn> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: xfa9anr71apayw5w8uh11sx7pmw8z7qk X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4E598C0002 X-Rspam-User: X-HE-Tag: 1683581828-499525 X-HE-Meta: U2FsdGVkX1/Kn53rs5sp8SEe+t19/uk1P+KhfqBJ2OVtYLYDyAdZ+1R5WtNYP6/5YKF8IraxImkctgHcQ5kdC6z1hxY/qzc/HGZnakncxmxAisfCYFjOUc8U2CYI/pHmNx7PyV3XlVehtA48O3qosxo8Z1NzGys+THhoVcI8CcGpS+/AcwoN0QJgKXnsZxnXd15ctTJqT5X/QK7AU6jAZGnQMEyVrjJXgIReWexsOds6DXwy9h2J0/YLmYCXMcO9+78Qvc1U90iOUd9jud/9REv9LLjBeljgfAtzNGbTh9sFdmWC5rkptk9ltBtr8qSrBb6GNGuhcK+qC0c3ySiFDnPsiJ5lprlnX+ySQyscL621qVrxJuXAcVcU+uBhcVBaJ0qi5i4WP0Is7uWqXy99/zrQLrjBtbG6CBTVAU3kHfmdhTUt0fRFh1pTuPoNtOxJ8NKqV3Lp/fDcryss7K79cf9YqGUSFKiMfSBin2plfL9MYEczRkGlhTFkMYECAiwNCcEiuF/enPhjFZThM2E433nriJ88dDnTDt0Yq/3yqAbUcI6XHsIsUxnNFx4aSCbd3y/KX2nr/O6VvIDibMfUWe7UcNO1BNfJ+jBRHHrJpdeN/8zjYW60ibT9Rhs+Qth1nUpTiNW1OT7/D5vExqwOCaLbl7NEOnyisDeryv0WaRpvvQ0AHKk+9JsKKBr2pUAbjXQsg/p474vJceKB4xfy8sY1j4HlhvZRgOceYtgZo9WN01FJH1NlPeQROMKG1DmZbR9gSBRzOtekfrT0Y+Xd2vTxTZCBwvgHgi6OmNpdI+vgeEfbZlYQkPDMSZvimf+H8vEgbKlAnQxrzusotwd+zPv5awLEWvx0gd7jerbKnjmpK2dzGnBQt/wYwuXou/VytWnsan3m/gY8aE5PyosSnnDCy3sC20FKFgxUw8qbp43MmjjORpqxd1MDtab/rDHjDI1jt+0jeybf/GLWBrq b7IdtHDr Tc2hj/RLoS4CgL0ybVZgmpeTjxrfiBXRsH2veIIGNlLErVlGzyC5FI+t0aK2prBY5xFhTRLYdRUm4htz5z2ddQxRvhKJuefSvHSLNsYmj+D4oHNySRlga9O//RFi34dDnBZUcK78y+e5BFV6+TnN3+7HAWAI6VMaUOF8DNg8jcRZK223on/yEb68F/9YcmPJZyksXqX0NcnzGtVLMsUC5YGHwxalSCUXqdZcgkv4uS/z6lPupf5lTLdhWFzzK5VQo53HTeKdNjbgIKuPwNz18Cr7rzkgInOnV4L2ev0SEVNN/VJJu2RwkgnoNr6fLg1qTBlbzQzjp8sVu51jet/MXtt3RW02nUEL9lKRdokrlzaLc5lyrn0ejY2OBettbtFX+B/UxXJ1oafsahTf963SZuDUTBWwPY45i+H8XaLYyso4kv4UYmoDCHC8kWkxKvEp7Uro520kcs8bppaNlhXmwHD/HdUCuHEXTb0R7QiP1xzj+K+iZOSO17LH8i0Y6MqrfaudICLkVQHwMrPsLFMfWiNFfRZAJmbyx0LiJE131TrI6uY/Qi+aCgioT1VBSKijRJt5jYCkSwLxtQeFZ4WPo4t24hCwxmdBbXhDMYU/3IqNV4RXOc2u0m154iGIaDAWF5cwx 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 08.05.23 23:27, Pasha Tatashin wrote: > On Sun, May 7, 2023 at 9:58 AM Ruihan Li wrote: >> >> Hi all, > > Hi Ruihan, > > Thank you for bisecting, and great analysis of the problem. > >> Recently, syzbot reported [1] ("kernel BUG in page_table_check_clear"). After >> some bisection, I found out that when usbdev_mmap calls remap_pfn_range on >> kmalloc'ed memory, it causes type confusion between struct folio and slab in >> page_table_check. As I will explain below, it seems that both usb-side and >> mm-side need some fixes. So I have cc'd linux-usb and linux-mm here, as well >> as their maintainers, to see whether there are any comments on the proposed >> way to fix. >> >> [1] https://lore.kernel.org/all/000000000000258e5e05fae79fc1@google.com/ >> >> To handle mmap requests for /dev/bus/usb/XXX/YYY, usbdev_mmap first allocates >> memory by calling usb_alloc_coherent and then maps it into the user space >> using remap_pfn_range: >> >> static int usbdev_mmap(struct file *file, struct vm_area_struct *vma) >> { >> // ... >> mem = usb_alloc_coherent(ps->dev, size, GFP_USER | __GFP_NOWARN, >> &dma_handle); >> // ... >> if (hcd->localmem_pool || !hcd_uses_dma(hcd)) { >> if (remap_pfn_range(vma, vma->vm_start, >> virt_to_phys(usbm->mem) >> PAGE_SHIFT, >> size, vma->vm_page_prot) < 0) { >> // ... >> } >> } >> // ... >> } >> >> Note that in this case, we consider the DMA-unavailable scenario, which, to be >> honest, is rare in practice. However, syzbot emulates USB devices using a >> module named dummy_hcd, and since these devices are emulated, DMA is not >> available at all. >> >> Meanwhile, usb_alloc_coherent calls hcd_buffer_alloc, which uses kmalloc for >> memory allocation: >> >> void *hcd_buffer_alloc( >> struct usb_bus *bus, >> size_t size, >> gfp_t mem_flags, >> dma_addr_t *dma >> ) >> { >> // ... >> if (!hcd_uses_dma(hcd)) { >> *dma = ~(dma_addr_t) 0; >> return kmalloc(size, mem_flags); >> } >> // ... >> } >> >> However, during the update of the page table to map the kmalloc'd page into >> the user space, page_table_check_set attempts to determine whether the page is >> anonymous using PageAnon: >> >> static void page_table_check_set(struct mm_struct *mm, unsigned long addr, >> unsigned long pfn, unsigned long pgcnt, >> bool rw) >> { >> // ... >> anon = PageAnon(page); >> for (i = 0; i < pgcnt; i++) { >> // ... >> if (anon) { >> BUG_ON(atomic_read(&ptc->file_map_count)); >> BUG_ON(atomic_inc_return(&ptc->anon_map_count) > 1 && rw); >> } else { >> BUG_ON(atomic_read(&ptc->anon_map_count)); >> BUG_ON(atomic_inc_return(&ptc->file_map_count) < 0); >> } >> // ... >> } >> // ... >> } >> >> This call to PageAnon is invalid for slab pages because slab reuses the bits >> in struct page/folio to store its internal states, and the anonymity bit only >> exists in struct page/folio. As a result, the counters are incorrectly updated >> and checked in page_table_check_set and page_table_check_clear, leading to the >> bug being raised. > > We should change anon boolean to be: > > anon = !PageSlab(page) && PageAnon(page); > > This way, we will have a correct way to determine anon pages, and the > rest will fall into file_map_count. The file (non-anon) PTEs are OK to > be double mapped, so there won't be any problems from page_table_check > point of view even if it is a slab page. I'm surprised that we allow mapping slab pages to user space. I somehow remember that this is a big no-no. Do we really want to allow that? Are there many such users or is this the only one? If we do support it, we might want to update some PageAnon() checks in mm/gup.c too to exclude slab pages ... -- Thanks, David / dhildenb