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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0894FC433F5 for ; Fri, 1 Oct 2021 23:37:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8FAAB61A8E for ; Fri, 1 Oct 2021 23:37:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8FAAB61A8E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 24C6094015B; Fri, 1 Oct 2021 19:37:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FB5E940121; Fri, 1 Oct 2021 19:37:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09CA594015B; Fri, 1 Oct 2021 19:37:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id F0CEF940121 for ; Fri, 1 Oct 2021 19:37:53 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B0EFB18446BBB for ; Fri, 1 Oct 2021 23:37:53 +0000 (UTC) X-FDA: 78649483626.17.D57ACB3 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf05.hostedemail.com (Postfix) with ESMTP id 6C161506DC34 for ; Fri, 1 Oct 2021 23:37:53 +0000 (UTC) Received: by mail-yb1-f179.google.com with SMTP id u32so23727465ybd.9 for ; Fri, 01 Oct 2021 16:37:53 -0700 (PDT) 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=tt7Hdb+hPYhUJtzg78OyXPTH1G9+C5jzb56pV825FZQ=; b=eLyjdUaPWiUSeVQ5w0qP3Shd6csqCSF3Dinc5Ah7hTICHORWETU35atAI7Uyok6vsn Ibk6m1JOMkW9PJ1Wpzb13yAlEAWmXUZdEZR3nIjA4rCmpU4z9tPTNc8cfGc1CZnekDoz QFtBpirtyfbNNqtu8Oj1hTnvGHaraB+5Qvtzn1RAnEQyTV9dc4gxBLXPGljeHhPiDBtA EyMOkuZZUZjySRoB5EwEWyn6hEaYbap/EvuoW0LwLn91c2p5yarYkhBTujBJbnGozngC S1ZWemAxLh86AxFx4//kAsKbc0utO0dSWdhzACNjUiMt8ZhcbQ67YUFjbatUlhZRQJ72 DxsA== 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=tt7Hdb+hPYhUJtzg78OyXPTH1G9+C5jzb56pV825FZQ=; b=2lrCQCh5vfhXhQT36PpJy8f281sYegEvgiyeYLeo99gmmPasUCZr8u85HD33OUvLJ1 mzNL2aE9V366hiKInvSDl3rvMUhkxUhAdEaux6U5/ib43FDODedNO4One0ynURznRuas eeBtjnt44LmKQEO3BKZ+1eEkS6oqkRQ5eutf7KnYKRsvhZ4tod3kXxxu3EoSysdj1zTS Lvp28x6UVhfdD+HCSAPJ+QHunnoRsLgukuGB/6ULMUn5L4uTC4yW3qlfZ9JPReUBV23d P5hg45XueNr8uT2L91aMno39FlYyqMTyXECAW7HNiDqkvcFSwTvqw1BBYyG6n/W9I45+ 5AuA== X-Gm-Message-State: AOAM5322FrhmTlp/UWMe43vYP9EFDrbCo5txYJ7DQCsR7cgUkW0UYXTU R6OMu+EelFdtPyDJziZ6CRGMQr6ewWeOskEUvqWpoA== X-Google-Smtp-Source: ABdhPJxamboFE4NPYJAmRT2znIQBkJMM7K5bSExj1BqiL3sMcVxvBS7HLXN98nT5tx6KAkbsfSTk992vy/WOeej18+o= X-Received: by 2002:a25:7415:: with SMTP id p21mr682439ybc.78.1633131472098; Fri, 01 Oct 2021 16:37:52 -0700 (PDT) MIME-Version: 1.0 References: <20211001215630.810592-1-eric.dumazet@gmail.com> <20211001154949.98956c092734590e781ce672@linux-foundation.org> In-Reply-To: <20211001154949.98956c092734590e781ce672@linux-foundation.org> From: Eric Dumazet Date: Fri, 1 Oct 2021 16:37:40 -0700 Message-ID: Subject: Re: [PATCH v2] mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind() To: Andrew Morton Cc: Eric Dumazet , linux-kernel , linux-mm , syzbot , "Huang, Ying" , Mel Gorman Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=eLyjdUaP; spf=pass (imf05.hostedemail.com: domain of edumazet@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=edumazet@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6C161506DC34 X-Stat-Signature: 1p4nrxugitpa843ac7oqpkj13fokyjjz X-HE-Tag: 1633131473-49383 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 Fri, Oct 1, 2021 at 3:49 PM Andrew Morton wrote: > > On Fri, 1 Oct 2021 14:56:30 -0700 Eric Dumazet wrote: > > > From: Eric Dumazet > > > > syzbot reported access to unitialized memory in mbind() [1] > > I'm lazy. What memory is being accessed-unintialized? I think you can clearly see that with this debug patch (courtesy of Alexander Potapenko) : (Then issue various mbind( ...MPOL_F_NUMA_BALANCING | MPOL_LOCAL ...) in a loop... ) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 1592b081c58e..95a4d71efe99 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -291,6 +291,7 @@ static struct mempolicy *mpol_new(unsigned short mode, unsigned short flags, } else if (nodes_empty(*nodes)) return ERR_PTR(-EINVAL); policy = kmem_cache_alloc(policy_cache, GFP_KERNEL); + memset(policy, 0xAA, sizeof(struct mempolicy)); if (!policy) return ERR_PTR(-ENOMEM); atomic_set(&policy->refcnt, 1); @@ -2256,9 +2257,12 @@ bool __mpol_equal(struct mempolicy *a, struct mempolicy *b) return false; if (a->flags != b->flags) return false; - if (mpol_store_user_nodemask(a)) + if (mpol_store_user_nodemask(a)) { + pr_err("struct mempolicy *a: %px, nodemask: %px\n", a, *(void**)&(a->w.user_nodemask)); + pr_err("struct mempolicy *b: %px, nodemask: %px\n", b, *(void**)&(b->w.user_nodemask)); if (!nodes_equal(a->w.user_nodemask, b->w.user_nodemask)) return false; + } switch (a->mode) { case MPOL_BIND: > > > Issue came with commit bda420b98505 ("numa balancing: migrate on > > fault among multiple bound nodes") > > No cc:stable? What's the worst-case user-visible impact here? I added the more precise tag : Fixes: bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes") I only put Fixes: tag, so that stable teams can use their automation just fine. worst-case impact, I am not sure if any application ever used this undocumented combinations of flags ? Also, it is generally advised that accessing garbage values has undocumented behavior. A host could for example crash (it certainly does with KMSAN)