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 2B3E4C54EE9 for ; Thu, 8 Sep 2022 22:34:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D16B8D0003; Thu, 8 Sep 2022 18:34:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 881388D0002; Thu, 8 Sep 2022 18:34:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 748878D0003; Thu, 8 Sep 2022 18:34:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 622238D0002 for ; Thu, 8 Sep 2022 18:34:04 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3CA9340177 for ; Thu, 8 Sep 2022 22:34:04 +0000 (UTC) X-FDA: 79890372408.11.F4CE99D Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf18.hostedemail.com (Postfix) with ESMTP id DE39F1C007D for ; Thu, 8 Sep 2022 22:34:03 +0000 (UTC) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-3450a7358baso154286907b3.13 for ; Thu, 08 Sep 2022 15:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=S8JRORyTZICqspExWp8dFqeKdvLhQE9ku6TSJxBJJi4=; b=BSTRJPDHzv4G0j+dsoiegy5mfXCHAjIaxdhRwK3Co3ptiLvva6/93LE0PJwqq+o7tb 3/dD1+SfS8/r7xitPLgrk2NxImvo5nR8u8hdNUIUoeAllbqHCPQsa2BACan6stxOPTs0 KpbHaL/NwDlNuOFnYv5HBbbomvpt3X1yp1W1vTIbx/gnTtGks8XLeqiJZfoA6nKj9swS L/VVATB84bAPMsu4//QQXbRElTQa/2O14I1cXf34zLmxbfr1JFaYO3h9t44FpX0HWNyz us0UzLm60U5YIhHXJ75Np6t9PFpgK/xTLWsDU2mfjtN+C+m4rQullZGJTrk3Lnzp4eQz WZuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=S8JRORyTZICqspExWp8dFqeKdvLhQE9ku6TSJxBJJi4=; b=SzP5ni7OpDICwYHFTPw9YiP6z5C+mDg/EUuz/ruwSX0rp7p29l3uLQz9OXKbB2l8oY m00vLwZw7N7sIojdyvIQpBVHDvSf+1nWEA/glAb0QQAaT6EV5yRbY0DwAHK3aJ2SA6DG 0JccTcpb6sW1VKLEYLBWs8Putw2QQ4YZq4S9Jlgzu/uW36fN/2IaVbygBoquV3O5CWSZ hcY3UVp8RxWWL/mW1YAObnuG56oxkBEjrsklru6ji1sCFWXmJ7m3Twh8oFcifJbV7KSO aSJPsHhIKeCmUJmDV1j2HgKSGimSIWEe8Si9mW4kuZzRHb6WS0igBe+bvMXr4ciXskNs R7Lw== X-Gm-Message-State: ACgBeo3qehGDLBBkevgg7N0uWH1mAlqQEut+z8eCszZ8iNoNoVLguefu YD5fNxOYQQSlquSqBOUZfXe2TxzQfdfq7bCXm0dhRA== X-Google-Smtp-Source: AA6agR6PJfUNYsqGTg/+zU8TxGOkg9IHJ4PzYgcYXR1jgRgg3FNLQcjDrGaqWbyEbuZfJBc2LFERYIS5UEH+uommeZQ= X-Received: by 2002:a81:f07:0:b0:347:3ebd:b563 with SMTP id 7-20020a810f07000000b003473ebdb563mr9554533ywp.409.1662676442935; Thu, 08 Sep 2022 15:34:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Thu, 8 Sep 2022 15:33:52 -0700 Message-ID: Subject: Re: BUG in binder_vma_close() at mmap_assert_locked() in stable v5.15 To: Carlos Llamas Cc: Andrew Morton , "Liam R. Howlett" , Michal Hocko , Guenter Roeck , Douglas Anderson , Christian Brauner , Greg Kroah-Hartman , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BSTRJPDH; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662676443; a=rsa-sha256; cv=none; b=PFCGzm98IR0AtYWLRbOD3ZTCIcdg03ELZXoGkaaoPrNY1noYMkiIv1Z5t03Ldxhr2LbJsU +BLIM5r7Gr0Y0unBkAstQOmxK2hFuZyzQB9IGV7K86r6htttzmn+e7fI7koJVx6tyKTmUx 2YT5PSA39OJmwcLWXfqIh6Q3Usvg7TY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662676443; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=S8JRORyTZICqspExWp8dFqeKdvLhQE9ku6TSJxBJJi4=; b=fQyQtXFDMgq+sp4qVdonUwgP93oL1oZ45K3+M3PbaDHSh26m+Upf9iTMaYisvEGPcrZROk Gqd6TNzRfiKc4s/p/bniQk+Itm/Vc7QfeCqzlYmhjvv9wE7o5spUndUq/A5nInL1/p6e49 IX/oPT0YgtWJutd4+GWUbEuZTJt3Eiw= X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DE39F1C007D Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BSTRJPDH; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: noiyijyf818c6js4erooc848up4poje7 X-Rspam-User: X-HE-Tag: 1662676443-126540 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 Thu, Sep 8, 2022 at 1:28 PM Carlos Llamas wrote: > > Hi, > > I've received several reports of a mmap_assert_locked() BUG triggering > at binder_alloc_vma_close() in the v5.15 stable tree. This makes sense > as the following two commits were recently picked for stable: > > a43cfc87caaf ("android: binder: stop saving a pointer to the VMA") > b0cab80ecd54 ("android: binder: fix lockdep check on clearing vma") > > In such commits mmap_asserts are added to binder_alloc_set_vma() which > is called back from vma->vm_ops->close() and file->f_op->mmap(). > > However, mmap_locking was only added to the exit_mmap() path in commit > f798a1d4f94d ("mm: fix use-after-free bug when mm->mmap is reused after > being freed") and since this patch doesn't exist in v5.15 stable tree > undoubtedly it leads to the following BUG: > > kernel BUG at include/linux/mmap_lock.h:156! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > [...] > Call trace: > binder_alloc_vma_close+0x14c/0x150 > binder_vma_close+0xa4/0x184 > remove_vma+0xa4/0x108 > exit_mmap+0x320/0x424 > __mmput+0xb4/0x2b4 > mmput+0x8c/0xb0 > exit_mm+0x51c/0x6c8 > do_exit+0x488/0x1bf4 > do_group_exit+0x118/0x270 > [...] > > Note that I have removed such asserts from the binder driver here: > https://lore.kernel.org/all/20220829201254.1814484-5-cmllamas@google.com/ > as a random driver didn't seem to me like the appropriate place to > validate the mm stack locking. Since this patch is not going to the > stable trees, the asserts still exist in v5.15. > > So, what is the proper fix for this v5.15 BUG? Should f798a1d4f94d > be picked for v5.15 stable? Or should binder be fixed instead? IIUC, the binder patches are backported to 5.15 kernel and they expect mmap_lock to be held during remove_vma() operation in exit_mmap(). However in 5.15 kernel that assumption is incorrect. In that case IMHO the backport needs to drop that invalid expectation. Thanks, Suren. > > Thanks, > -- > Carlos Llamas