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 D0C5AC433F5 for ; Tue, 22 Feb 2022 05:48:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 332618D0006; Tue, 22 Feb 2022 00:48:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 308028D0001; Tue, 22 Feb 2022 00:48:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F7838D0006; Tue, 22 Feb 2022 00:48:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 116888D0001 for ; Tue, 22 Feb 2022 00:48:13 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BE0E822904 for ; Tue, 22 Feb 2022 05:48:12 +0000 (UTC) X-FDA: 79169335224.01.4A264A2 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf08.hostedemail.com (Postfix) with ESMTP id 56678160003 for ; Tue, 22 Feb 2022 05:48:12 +0000 (UTC) Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-2d310db3812so161480117b3.3 for ; Mon, 21 Feb 2022 21:48: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=hw6aQJa1MO9WdpxwzimvLityGgLsFlQla0AXaHMQmt0=; b=q//0ngBw/9CR5mrn8X0xPqPq9wEjbNjeSbSLQaR1T9XnxZ6n6eOU/zM9nTaILAgbDj AbZb2CzrN8VVOPIZg8lcIqeo1AyHKbg9rHy33/6sqG+f6Jxs5gpFmcChMOkJzsrY3xgw YcBPrAMipOn34XET6lfU5xmem/NSO6dn5bfVUzx3vXqrcq5J26cdP9DraWBw9kth9RM4 ZEoIhB30eylsyqC+bBwoned+sm1fvSG980njnWDcZO+XUhtDNalHnyPWclNCojmomU9r pkQZkjfsXAbLe78VXjdYJzkjvpfaFQh7ffzpHoqI7ZmyMpfEntiQF9WrMYaJxrBknlJQ w13w== 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=hw6aQJa1MO9WdpxwzimvLityGgLsFlQla0AXaHMQmt0=; b=qQ4SlmC1wK8R3JrvuHun658fk8ynVUysYZXq/PzjmnX+LcLkmPVO9vXeYHyn40gEHi sVWsCXd0TkTJwib3To4DuoBg6UBS0B1vv9jX8fhIcy1WYyYkSJkA5c+IKlFP0jTVm+dF nXasgD5kl+4xdcdPyQ7YkTybKA3MA9HYFFu0Ze+C0e5Z7//IsLzcZpTvRy9f33kdifUR IUahpoDp3PNLFY7FGuJlmpwUBDJXfG9vBQw7qSIfxtSVTkNHXMhjHgc6c69YRMgnNaoe G3kHXhlWXSP5oBBIJsC3ooG3vKOnQFzSn42V4MiYrRRf33ejBInBmjs2RacSQh7Gg6Vn ZsBQ== X-Gm-Message-State: AOAM533fElHGoEMzjgCd5bcyzRKm2zZFZnX7Msaht4F4yrQkTc1NjWNI R9BeWpOsBhGgyFs7DVJZiqKFUcBZwfEzzNZ5AD+ekg== X-Google-Smtp-Source: ABdhPJyhDuclYQmodYIzN2CJ9eAgBf112KtTtES+r/ZuZFe3mtJx+Sv/y4TK/ne8vFOyQsWxtDM1mBcQMZ/Aa1QF7CM= X-Received: by 2002:a81:1748:0:b0:2d6:41ae:1384 with SMTP id 69-20020a811748000000b002d641ae1384mr22200124ywx.293.1645508891454; Mon, 21 Feb 2022 21:48:11 -0800 (PST) MIME-Version: 1.0 References: <20220211013032.623763-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 21 Feb 2022 21:48: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-Queue-Id: 56678160003 X-Stat-Signature: 3su85yysenwybww1a4ccoinj7diuhnee Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="q//0ngBw"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=surenb@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1645508892-28364 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, Feb 17, 2022 at 11:54 AM Suren Baghdasaryan wrote: > > 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 posted the new patchset that includes: 1. refactoring of the code suggested by Michal: https://lore.kernel.org/all/20220222054025.3412898-1-surenb@google.com 2. refcount overflow protection suggested by Michal: https://lore.kernel.org/all/20220222054025.3412898-2-surenb@google.com 3. UAF fix (originally implemented by this patch) reimplemented after the first two changes: https://lore.kernel.org/all/20220222054025.3412898-3-surenb@google.com Hopefully this sequence makes sense. Thanks, Suren. > > > > > 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