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=-12.1 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 C3145C433E6 for ; Mon, 31 Aug 2020 23:45:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 813FA20639 for ; Mon, 31 Aug 2020 23:45:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vKLyRZ+k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 813FA20639 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0737B6B0003; Mon, 31 Aug 2020 19:45:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 024306B0037; Mon, 31 Aug 2020 19:45:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA3336B0055; Mon, 31 Aug 2020 19:45:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id D23416B0003 for ; Mon, 31 Aug 2020 19:45:34 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9127E180AD802 for ; Mon, 31 Aug 2020 23:45:34 +0000 (UTC) X-FDA: 77212498188.25.side12_491399427093 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 5D4EC1804E3A1 for ; Mon, 31 Aug 2020 23:45:34 +0000 (UTC) X-HE-Tag: side12_491399427093 X-Filterd-Recvd-Size: 4647 Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Mon, 31 Aug 2020 23:45:33 +0000 (UTC) Received: by mail-lj1-f175.google.com with SMTP id r13so8788878ljm.0 for ; Mon, 31 Aug 2020 16:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=0QADmPJ3pJP8sMkX/yxajyr3yYhJMC3qgwVyMYQIlHQ=; b=vKLyRZ+kyD3hvbezSyIUNTPucb7tWIMc43/UVGnBPUV/E4JwjaVvULaadbtwOBddJm OVaDPl/rnn1JzQZJu1Glzg1fT7rFx72ne4wYM4gzy2kXp99F3uUs303Z4WppLkYCMf4d 6TaldNzGVLJSmlsjJdTJLIJ9IV9a+vCAqYEH7BhskBJpDW68N0K+COjvZpqF7OTDYhc2 qAbHxupiHpQgGrvvd0o5Zez/MC/8n+pFNrxHQnk8gRmDiHKAhnTiMSxl7C9lOErymYJG UTKgAe38kd7Ed8OL9KTktCxQtOwoARZkphT63DFyHNl/Fr0AmDN5ptERpefbbhgr8dXj kosQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=0QADmPJ3pJP8sMkX/yxajyr3yYhJMC3qgwVyMYQIlHQ=; b=ELZRnipJw0cq3dNrmhtamayqb7/r1iRA/DdX3/aKnPoUHRh0W2/pSWETY74vppQ8et M3TeQRpggQyeU8yOT6p2MQzrX/qTUipF+Fj+zoqsLIY6xgvrCbU/eU07TPAE/W0sXhJ+ qGcnObmswZImGgFC5mI60AZo6IvXuEdUm69fnj9Pxvf2MVYBKBtJhiVDOUyuE6VNOmVe j+YTFbErP6cKe9PsFpvxpyny40nR9Fca30Kvbh3MXO35MG7bfxN1VTakyKsZsjj0xD8R VXcLpnYKZ7Hnifyp90GyuhFmbQ77Il0f9KvawBu/JAyOsfODEBVjIdMEMqMEyg/bvJa4 LcnA== X-Gm-Message-State: AOAM530RBMLrPe046UbDVAmJRGnCkMZCbUlWKzcmah03c6O1Qpy4nvDc +6eSyWS7jBeGq3K174Cr9TicOpjwJSoZEMOeFoNpcA== X-Google-Smtp-Source: ABdhPJyN1IfSCTBMZo7erN2+t4wlBEpfwhLLPeP5dUh6Nb6oD9HqhzG19gbpNo6rkTk1cpXNObdD4O89/VgN8YlMf4c= X-Received: by 2002:a2e:9617:: with SMTP id v23mr1756141ljh.365.1598917532171; Mon, 31 Aug 2020 16:45:32 -0700 (PDT) MIME-Version: 1.0 From: Jann Horn Date: Tue, 1 Sep 2020 01:45:06 +0200 Message-ID: Subject: buggy-looking mm_struct refcounting in HFI1 infiniband driver To: Mike Marciniszyn , Dennis Dalessandro , Ira Weiny Cc: Linux-MM , Doug Ledford , linux-rdma@vger.kernel.org, Jason Gunthorpe , Dean Luick Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5D4EC1804E3A1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: Hi! mm_struct has two refcounts: ->mm_users for references that pin everything (including page tables, VMAs, ...) and ->mm_count (just protects the mm_struct itself and the pgd, but not the page tables or VMAs). struct hfi1_filedata has a member ->mm that holds a ->mm_count reference: static int hfi1_file_open(struct inode *inode, struct file *fp) { struct hfi1_filedata *fd; [...] fd->mm = current->mm; mmgrab(fd->mm); // increments ->mm_count [...] } It looks like that's from commit e0cf75deab8155334c8228eb7f097b15127d0a49 ("IB/hfi1: Fix mm_struct use after free"). However, e.g. the call chain hfi1_file_ioctl() -> user_exp_rcv_setup() -> hfi1_user_exp_rcv_setup() -> pin_rcv_pages() -> hfi1_acquire_user_pages() -> pin_user_pages_fast() can end up traversing VMAs without holding any ->mm_users reference, as far as I can tell. That will probably result in kernel memory corruption if that races the wrong way with an exiting task (with the ioctl() call coming from a task whose ->mm is different from fd->mm). Disclaimer: I haven't actually tested this - I just stumbled over it while working on some other stuff, and I don't have any infiniband hardware to test with. So it might well be that I just missed an mmget_not_zero() somewhere, or something like that. AFAICS the three options to fix this, if it indeed is a real bug, would be: 1) use mmget_not_zero() around any operations that need the VMAs and/or pagetables to be stable (if the mm_struct's virtual memory should disappear once all tasks that were using it have gone away) 2) take a long-term ->mm_users reference (generally frowned upon, but may be reasonable if you explicitly want to preserve mm contents even if all tasks that were using the mm have gone away) 3) bail out early on any operation where `current->mm != fd->mm` and declare that using the hfi1 fd from another process is not supported (but I haven't checked whether you might still have some code paths that will have to remotely operate on the mm_struct)