Linux-Integrity Archive on
 help / color / Atom feed
From: Eric Biggers <>
To: Mimi Zohar <>
Cc:, Al Viro <>
Subject: Re: [RFC PATCH] ima: fix ima_file_mmap circular locking dependency
Date: Fri, 12 Jul 2019 16:13:39 -0700
Message-ID: <20190712231339.GC701@sol.localdomain> (raw)
In-Reply-To: <>

Hi Mimi,

On Fri, Jul 12, 2019 at 04:41:37PM -0400, Mimi Zohar wrote:
> The LSM security_mmap_file hook is called before the mmap_sem is taken.
> This results in IMA taking the i_mutex before the mmap_sem, yet the
> normal locking order is mmap_sem, i_mutex.
> To resolve this problem, rename and call ima_mmap_file() after taking
> the mmap_sem.

I don't think this is correct.  The normal order is i_mutex, then mmap_sem.
E.g., for buffered writes i_mutex is taken, then when each page is written the
page may have to be faulted into memory which takes mmap_sem.

What seems to have happened is that due to your patch "ima: verify mprotect
change is consistent with mmap policy" which was in linux-next for a while,
syzbot found a reproducer on next-20190531 for
"possible deadlock in process_measurement"
which already had an open syzbot report for some other reason, possibly
overlayfs-related.  The same mprotect issue also got reported in 2 other syzbot
reports, "possible deadlock in get_user_pages_unlocked (2)" and
"possible deadlock in __do_page_fault (2)".

Since your patch was dropped from linux-next, the issue no longer exists.
I invalidated the other 2 reports for you but I didn't notice this one because
it was a much older syzbot report.

So I suggest just invalidating the report "possible deadlock in
process_measurement" too, unless you think you think the older overlayfs-related
deadlock report is still valid and actionable.  It doesn't have a reproducer
and was last seen 5 months ago, so it *might* be stale:

- Eric

  reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12 20:41 Mimi Zohar
2019-07-12 23:13 ` Eric Biggers [this message]
2019-07-14 16:48   ` Mimi Zohar

Reply instructions:

You may reply publically 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:

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

  git send-email \
    --in-reply-to=20190712231339.GC701@sol.localdomain \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Integrity Archive on

Archives are clonable:
	git clone --mirror linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ \
	public-inbox-index linux-integrity

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox