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 D7859C433EF for ; Thu, 17 Feb 2022 19:54:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63DBD8D0006; Thu, 17 Feb 2022 14:54:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5ECB28D0001; Thu, 17 Feb 2022 14:54:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48D868D0006; Thu, 17 Feb 2022 14:54:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id 3BBBB8D0001 for ; Thu, 17 Feb 2022 14:54:13 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E363B998B1 for ; Thu, 17 Feb 2022 19:54:12 +0000 (UTC) X-FDA: 79153323144.13.D717589 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf17.hostedemail.com (Postfix) with ESMTP id 437954000F for ; Thu, 17 Feb 2022 19:54:12 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-2d07ae0b1c0so44126977b3.2 for ; Thu, 17 Feb 2022 11:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CY03vuKHIipPaIy4G74R9XCKkPzAcd7M3s3fpInivhA=; b=Zqu/g+7VZQJs9deYRXvrVTIVbE6RVmPdkzUvltXlnz/pz9eh/v39w8IhGUv4Cp9OYM OSSYDblf2WSUnxCXIj3sYpyW6W6Px7mtt0zpTdNjI91ONX3PKpSwtWRD/X9w7kixghv+ hBJ/7gf2GQlJeU28ZtrDTtI+VFGee+BV8WL/SOkL8lrIww97jp4oJKdKT+4e+3pB+WOP o1MDBIvwyaDSUP7piAgCiHzZ7GQGfqft+Ze5D750C96dWtJllyKG3D7ao0uzpJ1mScze WoJsTVgqfCwPFqRJQy0uthHG8ywFUm9WfGEWfAB7vVDE/v7iTtwmsI3+5w5+1vBxb62h 0sog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CY03vuKHIipPaIy4G74R9XCKkPzAcd7M3s3fpInivhA=; b=lQ0Q49uSiLTsU3zkOurUFrWXkD0jap2X9yvMOoAwtOE+SQDwSGvcj57qhpdfJidszY 6Jr5miuzS80ZgZf0dQI5X4Tk2taayQDtnEAdviFnFy4ku6AyGK0v/Zey8FiL4aR/jK0p RHoLqgtU6yreaeF9GkCU+hDEkgdgXwEvogMKoIH9oqviu5YvW/CnMmSRqF2X/shNZ+aZ o05z1ZdPC5Dn9mFd5wIIiEC8clrAuhuBVXOcK09GWeTgyNOdvwP/1i82IYCzq4mhOi/7 9g+Ok5BeYoB5Mv/CjxdBM39PFiK3N53nn8uXNp9e/Abd9ZiJY3BLLKM/YmgtyAUi7LOH bZQA== X-Gm-Message-State: AOAM5300JjhHu2qj031zProTrZk0f0I+GRF6lDvEu6dus7zZpDhtwl9z oIeLu/XhIBCD6YuxDlYbPAvwyWxsWKf6CSvPqzlNDA== X-Google-Smtp-Source: ABdhPJyT2mtE7BfLv9CuhSal0ghswn//AN1A619CSO+rB8TDmoZHs2sOAvPmEG3am2YYXgZHn1fzVIRvSUZumnflswc= X-Received: by 2002:a81:334e:0:b0:2d0:aeef:fcd2 with SMTP id z75-20020a81334e000000b002d0aeeffcd2mr4216866ywz.180.1645127651380; Thu, 17 Feb 2022 11:54:11 -0800 (PST) MIME-Version: 1.0 References: <20220211013032.623763-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 17 Feb 2022 11:54:00 -0800 Message-ID: Subject: Re: [PATCH v3 1/1] mm: fix use-after-free when anon vma name is used after vma is freed To: Michal Hocko Cc: Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , Kees Cook , Matthew Wilcox , "Kirill A . Shutemov" , Vlastimil Babka , Johannes Weiner , "Eric W. Biederman" , Christian Brauner , legion@kernel.org, ran.xiaokai@zte.com.cn, sashal@kernel.org, Chris Hyser , Davidlohr Bueso , Peter Collingbourne , caoxiaofeng@yulong.com, David Hildenbrand , Cyrill Gorcunov , linux-mm , LKML , kernel-team , syzbot+aa7b3d4b35f9dc46a366@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 437954000F X-Stat-Signature: jms6u5gnuqqijk51mfsrngszotuz46ae X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="Zqu/g+7V"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1645127652-785206 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 Wed, Feb 16, 2022 at 12:06 AM Michal Hocko wrote: > > On Tue 15-02-22 15:02:54, Suren Baghdasaryan wrote: > > On Tue, Feb 15, 2022 at 12:05 PM Michal Hocko wrote: > > > > > > One thing I was considering is to check agains ref counte overflo (a > > > deep process chain with many vmas could grow really high. ref_count > > > interface doesn't provide any easy way to check for overflows as far as > > > I could see from a quick glance so I gave up there but the logic would > > > be really straightforward. We just create a new anon_vma_name with the same > > > content and use it when duplicating if the usage grow really > > > (arbitrarily) high. > > > > I went over proposed changes. I see a couple small required fixes > > (resetting the name to NULL seems to be missing and I think > > dup_vma_anon_name needs some tweaking) but overall quite > > straight-forward. > > OK, great that this makes sense to you. As I've said I didn't really go > into details, not even dared to boot that to test. So it will very > likely need some more work but I do not expect this to grow much. > > > I'll post a separate patch to do this refactoring. > > The original patch is fixing the UAF issue, so I don't want to mix it > > with refactoring. Please let me know if you see an issue with > > separating it that way. > > Well, I am not sure TBH. Look at diffstats. Your fix > 2 files changed, 63 insertions(+), 17 deletions(-) > the refactoring which should fix this and potentially others that might > be still lurking there (because mixing shared pointers and their internal > objects just begs for problems) is > 7 files changed, 63 insertions(+), 86 deletions(-) > > more files touched for sure but the net result is much more clear and a > much more code removed. > The overflow logic would make it bigger but I guess the existing scheme > needs it as well. Ok, I'll see how to slice it after it's complete and tested. Thanks for the input! > > I would also claim that both approaches are really painful to review > because the existing model spreads into several areas and it is not > really clear you caught them all just by staring into the diff so both > will be rather painful to backport to older kernels. Fortunately this > would be only 5.17. > -- > Michal Hocko > SUSE Labs