linux-kernel - Re: [PATCH 1/3] ima: Remove inode lock

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: <e89f6b61-a57f-4848-87f1-8e2282bc5aea@lucifer.local>
Date: Fri, 18 Oct 2024 12:00:22 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Roberto Sassu <roberto.sassu@...weicloud.com>,
        Paul Moore <paul@...l-moore.com>, ebpqwerty472123@...il.com,
        kirill.shutemov@...ux.intel.com, zohar@...ux.ibm.com,
        dmitry.kasatkin@...il.com, eric.snowberg@...cle.com, jmorris@...ei.org,
        serge@...lyn.com, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
        bpf@...r.kernel.org, Roberto Sassu <roberto.sassu@...wei.com>,
        linux-mm@...ck.org, akpm@...ux-foundation.org, vbabka@...e.cz,
        linux-fsdevel@...r.kernel.org, Liam Howlett <liam.howlett@...cle.com>,
        Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 1/3] ima: Remove inode lock

+ Liam, Jann

On Fri, Oct 18, 2024 at 01:49:06PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 18, 2024 at 11:24:06AM +0200, Roberto Sassu wrote:
> > Probably it is hard, @Kirill would there be any way to safely move
> > security_mmap_file() out of the mmap_lock lock?
>
> What about something like this (untested):
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index dd4b35a25aeb..03473e77d356 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1646,6 +1646,26 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start, unsigned long, size,
>  	if (pgoff + (size >> PAGE_SHIFT) < pgoff)
>  		return ret;
>
> +	if (mmap_read_lock_killable(mm))
> +		return -EINTR;
> +
> +	vma = vma_lookup(mm, start);
> +
> +	if (!vma || !(vma->vm_flags & VM_SHARED)) {
> +		mmap_read_unlock(mm);
> +		return -EINVAL;
> +	}
> +
> +	file = get_file(vma->vm_file);
> +
> +	mmap_read_unlock(mm);
> +
> +	ret = security_mmap_file(vma->vm_file, prot, flags);

Accessing VMA fields without any kind of lock is... very much not advised.

I'm guessing you meant to say:

	ret = security_mmap_file(file, prot, flags);

Here? :)

I see the original code did this, but obviously was under an mmap lock.

I guess given you check that the file is the same below this.... should be
fine? Assuming nothing can come in and invalidate the security_mmap_file()
check in the mean time somehow?

Jann any thoughts?


> +	if (ret) {
> +		fput(file);
> +		return ret;
> +	}
> +
>  	if (mmap_write_lock_killable(mm))
>  		return -EINTR;
>
> @@ -1654,6 +1674,9 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start, unsigned long, size,
>  	if (!vma || !(vma->vm_flags & VM_SHARED))
>  		goto out;
>
> +	if (vma->vm_file != file)
> +		goto out;
> +
>  	if (start + size > vma->vm_end) {
>  		VMA_ITERATOR(vmi, mm, vma->vm_end);
>  		struct vm_area_struct *next, *prev = vma;
> @@ -1688,16 +1711,11 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start, unsigned long, size,
>  	if (vma->vm_flags & VM_LOCKED)
>  		flags |= MAP_LOCKED;
>
> -	file = get_file(vma->vm_file);
> -	ret = security_mmap_file(vma->vm_file, prot, flags);
> -	if (ret)
> -		goto out_fput;
>  	ret = do_mmap(vma->vm_file, start, size,
>  			prot, flags, 0, pgoff, &populate, NULL);
> -out_fput:
> -	fput(file);
>  out:
>  	mmap_write_unlock(mm);
> +	fput(file);
>  	if (populate)
>  		mm_populate(ret, populate);
>  	if (!IS_ERR_VALUE(ret))
> --
>   Kiryl Shutsemau / Kirill A. Shutemov