linux-kernel - Re: [PATCH AUTOSEL 4.14 62/95] mm, memory_hotplug: initialize struct pages for the full memory section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 May 2019 12:58:00 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
        Mikhail Zaslonko <zaslonko@...ux.ibm.com>,
        Gerald Schaefer <gerald.schaefer@...ibm.com>,
        Michal Hocko <mhocko@...nel.org>,
        Michal Hocko <mhocko@...e.com>,
        Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
        Pasha Tatashin <Pavel.Tatashin@...rosoft.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        linux-mm <linux-mm@...ck.org>
Subject: Re: [PATCH AUTOSEL 4.14 62/95] mm, memory_hotplug: initialize struct
 pages for the full memory section

On Tue, May 07, 2019 at 09:31:10AM -0700, Alexander Duyck wrote:
>On Mon, May 6, 2019 at 10:40 PM Sasha Levin <sashal@...nel.org> wrote:
>>
>> From: Mikhail Zaslonko <zaslonko@...ux.ibm.com>
>>
>> [ Upstream commit 2830bf6f05fb3e05bc4743274b806c821807a684 ]
>>
>> If memory end is not aligned with the sparse memory section boundary,
>> the mapping of such a section is only partly initialized.  This may lead
>> to VM_BUG_ON due to uninitialized struct page access from
>> is_mem_section_removable() or test_pages_in_a_zone() function triggered
>> by memory_hotplug sysfs handlers:
>>
>> Here are the the panic examples:
>>  CONFIG_DEBUG_VM=y
>>  CONFIG_DEBUG_VM_PGFLAGS=y
>>
>>  kernel parameter mem=2050M
>>  --------------------------
>>  page:000003d082008000 is uninitialized and poisoned
>>  page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
>>  Call Trace:
>>  ( test_pages_in_a_zone+0xde/0x160)
>>    show_valid_zones+0x5c/0x190
>>    dev_attr_show+0x34/0x70
>>    sysfs_kf_seq_show+0xc8/0x148
>>    seq_read+0x204/0x480
>>    __vfs_read+0x32/0x178
>>    vfs_read+0x82/0x138
>>    ksys_read+0x5a/0xb0
>>    system_call+0xdc/0x2d8
>>  Last Breaking-Event-Address:
>>    test_pages_in_a_zone+0xde/0x160
>>  Kernel panic - not syncing: Fatal exception: panic_on_oops
>>
>>  kernel parameter mem=3075M
>>  --------------------------
>>  page:000003d08300c000 is uninitialized and poisoned
>>  page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
>>  Call Trace:
>>  ( is_mem_section_removable+0xb4/0x190)
>>    show_mem_removable+0x9a/0xd8
>>    dev_attr_show+0x34/0x70
>>    sysfs_kf_seq_show+0xc8/0x148
>>    seq_read+0x204/0x480
>>    __vfs_read+0x32/0x178
>>    vfs_read+0x82/0x138
>>    ksys_read+0x5a/0xb0
>>    system_call+0xdc/0x2d8
>>  Last Breaking-Event-Address:
>>    is_mem_section_removable+0xb4/0x190
>>  Kernel panic - not syncing: Fatal exception: panic_on_oops
>>
>> Fix the problem by initializing the last memory section of each zone in
>> memmap_init_zone() till the very end, even if it goes beyond the zone end.
>>
>> Michal said:
>>
>> : This has alwways been problem AFAIU.  It just went unnoticed because we
>> : have zeroed memmaps during allocation before f7f99100d8d9 ("mm: stop
>> : zeroing memory during allocation in vmemmap") and so the above test
>> : would simply skip these ranges as belonging to zone 0 or provided a
>> : garbage.
>> :
>> : So I guess we do care for post f7f99100d8d9 kernels mostly and
>> : therefore Fixes: f7f99100d8d9 ("mm: stop zeroing memory during
>> : allocation in vmemmap")
>>
>> Link: http://lkml.kernel.org/r/20181212172712.34019-2-zaslonko@linux.ibm.com
>> Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
>> Signed-off-by: Mikhail Zaslonko <zaslonko@...ux.ibm.com>
>> Reviewed-by: Gerald Schaefer <gerald.schaefer@...ibm.com>
>> Suggested-by: Michal Hocko <mhocko@...nel.org>
>> Acked-by: Michal Hocko <mhocko@...e.com>
>> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
>> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
>> Cc: Dave Hansen <dave.hansen@...el.com>
>> Cc: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
>> Cc: Pasha Tatashin <Pavel.Tatashin@...rosoft.com>
>> Cc: Martin Schwidefsky <schwidefsky@...ibm.com>
>> Cc: Heiko Carstens <heiko.carstens@...ibm.com>
>> Cc: <stable@...r.kernel.org>
>> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>> Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
>> Signed-off-by: Sasha Levin <alexander.levin@...rosoft.com>
>> ---
>>  mm/page_alloc.c | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>
>Wasn't this patch reverted in Linus's tree for causing a regression on
>some platforms? If so I'm not sure we should pull this in as a
>candidate for stable should we, or am I missing something?

I saw a follow-up patch that should be queued too, but I didn't see that
this one got reverted.

--
Thanks,
Sasha