linux-kernel - Re: linux 4.1-rc7 deadlock

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]

Message-ID: <alpine.LSU.2.11.1506111246170.6716@eggly.anvils>
Date:	Thu, 11 Jun 2015 13:06:04 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Morten Stevens <mstevens@...oraproject.org>
cc:	Daniel Wagner <wagi@...om.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Dave Chinner <david@...morbit.com>,
	Eric Paris <eparis@...hat.com>,
	Eric Sandeen <esandeen@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: linux 4.1-rc7 deadlock

On Tue, 9 Jun 2015, Morten Stevens wrote:
> 2015-06-09 16:10 GMT+02:00 Daniel Wagner <wagi@...om.org>:
> > On 06/09/2015 01:54 PM, Morten Stevens wrote:
> >> [   28.193327]  Possible unsafe locking scenario:
> >>
> >> [   28.194297]        CPU0                    CPU1
> >> [   28.194774]        ----                    ----
> >> [   28.195254]   lock(&mm->mmap_sem);
> >> [   28.195709]                                lock(&xfs_dir_ilock_class);
> >> [   28.196174]                                lock(&mm->mmap_sem);
> >> [   28.196654]   lock(&isec->lock);
> >> [   28.197108]
> >
> > [...]
> >
> >> Any ideas?
> >
> > I think you hit the same problem many have already reported:
> >
> > https://lkml.org/lkml/2015/3/30/594
> 
> Yes, that sounds very likely. But that was about 1 month ago, so I
> thought that it has been fixed in the last weeks?

It's not likely to get fixed without Cc'ing the right people.

This appears to be the same as Prarit reported to linux-mm on
2014/09/10.  Dave Chinner thinks it's a shmem bug, I disagree,
but I am hopeful that it can be easily fixed at the shmem end.

Here's the patch I suggested nine months ago: but got no feedback,
so it remains Not-Yet-Signed-off-by.  Please, if you find this works
(and does not just delay the lockdep conflict until a little later),
do let me know, then I can add some Tested-bys and send it to Linus.

mm: shmem_zero_setup skip security check and lockdep conflict with XFS

It appears that, at some point last year, XFS made directory handling
changes which bring it into lockdep conflict with shmem_zero_setup():
it is surprising that mmap() can clone an inode while holding mmap_sem,
but that has been so for many years.

Since those few lockdep traces that I've seen all implicated selinux,
I'm hoping that we can use the __shmem_file_setup(,,,S_PRIVATE) which
v3.13's commit c7277090927a ("security: shmem: implement kernel private
shmem inodes") introduced to avoid LSM checks on kernel-internal inodes:
the mmap("/dev/zero") cloned inode is indeed a kernel-internal detail.

This also covers the !CONFIG_SHMEM use of ramfs to support /dev/zero
(and MAP_SHARED|MAP_ANONYMOUS).  I thought there were also drivers
which cloned inode in mmap(), but if so, I cannot locate them now.

Reported-by: Prarit Bhargava <prarit@...hat.com>
Reported-by: Daniel Wagner <wagi@...om.org>
Reported-by: Morten Stevens <mstevens@...oraproject.org>
Not-Yet-Signed-off-by: Hugh Dickins <hughd@...gle.com>
---

 mm/shmem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 4.1-rc7/mm/shmem.c	2015-04-26 19:16:31.352191298 -0700
+++ linux/mm/shmem.c	2015-06-11 11:08:21.042745594 -0700
@@ -3401,7 +3401,7 @@ int shmem_zero_setup(struct vm_area_stru
 	struct file *file;
 	loff_t size = vma->vm_end - vma->vm_start;

-	file = shmem_file_setup("dev/zero", size, vma->vm_flags);
+	file = __shmem_file_setup("dev/zero", size, vma->vm_flags, S_PRIVATE);
 	if (IS_ERR(file))
 		return PTR_ERR(file);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/