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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 09269C43460 for ; Mon, 10 May 2021 14:12:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD9AD61108 for ; Mon, 10 May 2021 14:12:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233641AbhEJONN (ORCPT ); Mon, 10 May 2021 10:13:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233706AbhEJOKF (ORCPT ); Mon, 10 May 2021 10:10:05 -0400 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 876C1C0610E5 for ; Mon, 10 May 2021 06:50:34 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id 76so15312426qkn.13 for ; Mon, 10 May 2021 06:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+2U891pcT5PFaAL7+dZJNGYBFLIb+qctBvykRURXgBY=; b=dACYFzmZp5FCubbaz661EkjXMEr4yIw8M3uTK3Kyf9WGXPYwdZw+Te0aQwLTIgwwC2 IcIyUfISzla30F1Y5z5YNyfFMSuvpPToFEKyFwyWyzNO8J90FAq4FSLctkLmbUnqXieu lMQ7sIa6zzDWNW+3ZAA/Ywi2wnST8RvZfOXC1jXTR/nDU/u1OUAIwV5METsf0kVOPHrk PIuKStNqOQCBo7BK5+duLO5e2wBIi32E+Rgu2kNOG2SYryYXUN5IAmaJPspud5x7d6Vf 5XGHOc/1cpdW83EDoXATbw25gMJUpTl30B68jCIFcCNIzm8fMivAz/aG2nH3kKyIFqz2 KzIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+2U891pcT5PFaAL7+dZJNGYBFLIb+qctBvykRURXgBY=; b=ULX/m6m2L9FnspI6oJEUxKcg/eLD9D9YJE6pkQKDYaF/XysJUJt5PH0J9PRlGcsH8x dMK2u3n5BLxkrNZqzskeOmm1uf3ChZi+1NsEbMDdmHyUiA61H4RUzgbc3xwClAGXScOE NBkJ+9DPk6EYpyCJh/4DICkFIkef0AE4glQLc3kYEEWW+plKGde/1gHO23ScXUgjn+02 gInNN709kGJZg14n2x15YREYitPgQygyDBdtTV79ecqUFxi+7ehCnKpe/h9xOkoFEw1n jzV5pCXOqwvp31TS3Amc01pAiC2wTP/0YMiR6mbHDpbBu8dIQJRJaKybL3iM3W7VXdIp hW1g== X-Gm-Message-State: AOAM530kKcqxF0INy8+NBfwGLK9S3uOmUdI564cQdJ+TnIZVG6cHnHzt 5ZZVtoY9Mx0bTMiajiIT5Oq2Hg== X-Google-Smtp-Source: ABdhPJzBvEXIq3ZKj83MNPLUEszsweYjMFeVQA7SyU/yis3HOqTzVmEhu9DH0fP04ViEgC4gr5a3yA== X-Received: by 2002:a05:620a:4543:: with SMTP id u3mr22610464qkp.118.1620654633736; Mon, 10 May 2021 06:50:33 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-47-55-113-94.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.113.94]) by smtp.gmail.com with ESMTPSA id e7sm11644631qth.27.2021.05.10.06.50.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 May 2021 06:50:32 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1lg6Ip-004ZFk-QY; Mon, 10 May 2021 10:50:31 -0300 Date: Mon, 10 May 2021 10:50:31 -0300 From: Jason Gunthorpe To: Linus Torvalds Cc: Daniel Vetter , Tomasz Figa , Marek Szyprowski , Mauro Carvalho Chehab , DRI Development , LKML , Linux-MM , Linux ARM , Linux Media Mailing List , linux-samsung-soc@vger.kernel.org Subject: Re: [PULL] topic/iomem-mmap-vs-gup Message-ID: <20210510135031.GF2047089@ziepe.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org On Sat, May 08, 2021 at 09:46:41AM -0700, Linus Torvalds wrote: > I think follow_pfn() is ok for the actual "this is not a 'struct page' > backed area", and disabling that case is wrong even going forward. Every place we've audited using follow_pfn() has been shown to have some use-after-free bugs like Daniel describes, and a failure to check permissions bug too. All the other follow_pfn() users were moved to follow_pte() to fix the permissions check and this shifts the use-after-free bug away from being inside an MM API and into the caller mis-using the API by, say, extracting and using the PFN outside the pte lock. eg look at how VFIO wrongly uses follow_pte(): static int follow_fault_pfn() ret = follow_pte(vma->vm_mm, vaddr, &ptep, &ptl); *pfn = pte_pfn(*ptep); pte_unmap_unlock(ptep, ptl); // no protection that pte_pfn() is still valid! use_pfn(*pfn) v4l is the only user that still has the missing permissions check security bug too - so there is no outcome that should keep follow_pfn() in the tree. At worst v4l should change to follow_pte() and use it wrongly like VFIO. At best we should delete all the v4l stuff. Daniel I suppose we missed this relation to follow_pte(), so I agree that keeping a unsafe_follow_pfn() around is not good. Regards, Jason