From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:39184 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114AbbDZJj2 (ORCPT ); Sun, 26 Apr 2015 05:39:28 -0400 Subject: Patch "mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support" has been added to the 3.10-stable tree To: kirill.shutemov@linux.intel.com, aarcange@redhat.com, gregkh@linuxfoundation.org, long.wanglong@huawei.com, sasha.levin@oracle.com, torvalds@linux-foundation.org Cc: , From: Date: Sun, 26 Apr 2015 11:39:17 +0200 Message-ID: <143004115756145@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support to the 3.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: mm-fix-null-pointer-dereference-in-madvise-madv_willneed-support.patch and it can be found in the queue-3.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From ee53664bda169f519ce3c6a22d378f0b946c8178 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Fri, 20 Dec 2013 15:10:03 +0200 Subject: mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support From: "Kirill A. Shutemov" commit ee53664bda169f519ce3c6a22d378f0b946c8178 upstream. Sasha Levin found a NULL pointer dereference that is due to a missing page table lock, which in turn is due to the pmd entry in question being a transparent huge-table entry. The code - introduced in commit 1998cc048901 ("mm: make madvise(MADV_WILLNEED) support swap file prefetch") - correctly checks for this situation using pmd_none_or_trans_huge_or_clear_bad(), but it turns out that that function doesn't work correctly. pmd_none_or_trans_huge_or_clear_bad() expected that pmd_bad() would trigger if the transparent hugepage bit was set, but it doesn't do that if pmd_numa() is also set. Note that the NUMA bit only gets set on real NUMA machines, so people trying to reproduce this on most normal development systems would never actually trigger this. Fix it by removing the very subtle (and subtly incorrect) expectation, and instead just checking pmd_trans_huge() explicitly. Reported-by: Sasha Levin Acked-by: Andrea Arcangeli [ Additionally remove the now stale test for pmd_trans_huge() inside the pmd_bad() case - Linus ] Signed-off-by: Linus Torvalds Cc: Wang Long Signed-off-by: Greg Kroah-Hartman --- include/asm-generic/pgtable.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -550,11 +550,10 @@ static inline int pmd_none_or_trans_huge #ifdef CONFIG_TRANSPARENT_HUGEPAGE barrier(); #endif - if (pmd_none(pmdval)) + if (pmd_none(pmdval) || pmd_trans_huge(pmdval)) return 1; if (unlikely(pmd_bad(pmdval))) { - if (!pmd_trans_huge(pmdval)) - pmd_clear_bad(pmd); + pmd_clear_bad(pmd); return 1; } return 0; Patches currently in stable-queue which might be from kirill.shutemov@linux.intel.com are queue-3.10/mm-fix-null-pointer-dereference-in-madvise-madv_willneed-support.patch