linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Colin Ian King <colin.king@canonical.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	stable@vger.kernel.org, linux-mm@kvack.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: bug report: hugetlbfs: use i_mmap_rwsem for more pmd sharing, synchronization
Date: Thu, 27 Dec 2018 11:44:53 +0000	[thread overview]
Message-ID: <5c8be807-03cd-991d-c79b-3c10a4d6d67b@canonical.com> (raw)

Hi,

Static analysis with CoverityScan on linux-next detected a potential
null pointer dereference with the following commit:

>From d8a1051ed4ba55679ef24e838a1942c9c40f0a14 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz@oracle.com>
Date: Sat, 22 Dec 2018 10:55:57 +1100
Subject: [PATCH] hugetlbfs: use i_mmap_rwsem for more pmd sharing

The earlier check implies that "mapping" may be a null pointer:

var_compare_op: Comparing mapping to null implies that mapping might be
null.

1008        if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&
1009            mapping_cap_writeback_dirty(mapping)) {

..however later "mapper" is dereferenced when it may be potentially null:

1034                /*
1035                 * For hugetlb pages, try_to_unmap could potentially
call
1036                 * huge_pmd_unshare.  Because of this, take semaphore in
1037                 * write mode here and set TTU_RMAP_LOCKED to
indicate we
1038                 * have taken the lock at this higer level.
1039                 */
    CID 1476097 (#1 of 1): Dereference after null check (FORWARD_NULL)

var_deref_model: Passing null pointer mapping to
i_mmap_lock_write, which dereferences it.

1040                i_mmap_lock_write(mapping);
1041                unmap_success = try_to_unmap(hpage,
ttu|TTU_RMAP_LOCKED);
1042                i_mmap_unlock_write(mapping);


Colin

WARNING: multiple messages have this Message-ID
From: Colin Ian King <colin.king@canonical.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	stable@vger.kernel.org, linux-mm@kvack.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: bug report: hugetlbfs: use i_mmap_rwsem for more pmd sharing, synchronization
Date: Thu, 27 Dec 2018 11:44:53 +0000	[thread overview]
Message-ID: <5c8be807-03cd-991d-c79b-3c10a4d6d67b@canonical.com> (raw)
Message-ID: <20181227114453.8BKMnVf5yZ2XN6NylRtABHxRebAUWOkKGjSjlamL7Cw@z> (raw)

Hi,

Static analysis with CoverityScan on linux-next detected a potential
null pointer dereference with the following commit:

From d8a1051ed4ba55679ef24e838a1942c9c40f0a14 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz@oracle.com>
Date: Sat, 22 Dec 2018 10:55:57 +1100
Subject: [PATCH] hugetlbfs: use i_mmap_rwsem for more pmd sharing

The earlier check implies that "mapping" may be a null pointer:

var_compare_op: Comparing mapping to null implies that mapping might be
null.

1008        if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&
1009            mapping_cap_writeback_dirty(mapping)) {

..however later "mapper" is dereferenced when it may be potentially null:

1034                /*
1035                 * For hugetlb pages, try_to_unmap could potentially
call
1036                 * huge_pmd_unshare.  Because of this, take semaphore in
1037                 * write mode here and set TTU_RMAP_LOCKED to
indicate we
1038                 * have taken the lock at this higer level.
1039                 */
    CID 1476097 (#1 of 1): Dereference after null check (FORWARD_NULL)

var_deref_model: Passing null pointer mapping to
i_mmap_lock_write, which dereferences it.

1040                i_mmap_lock_write(mapping);
1041                unmap_success = try_to_unmap(hpage,
ttu|TTU_RMAP_LOCKED);
1042                i_mmap_unlock_write(mapping);


Colin


             reply	other threads:[~2018-12-27 11:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-27 11:44 Colin Ian King [this message]
2018-12-27 11:44 ` Colin Ian King
2018-12-27 19:24 ` Mike Kravetz
2018-12-28  2:45   ` Andrew Morton
2018-12-28  5:26     ` Mike Kravetz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5c8be807-03cd-991d-c79b-3c10a4d6d67b@canonical.com \
    --to=colin.king@canonical.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=sfr@canb.auug.org.au \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox