linux-kernel - Re: [RFC V2] fs/kcore: change copy_to_user to copy_in

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] [day] [month] [year] [list]

Date:	Thu, 20 Aug 2015 15:16:41 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	yalin wang <yalin.wang2010@...il.com>
Cc:	bp@...e.de, mingo@...nel.org, dave@...1.net, bhe@...hat.com,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC V2] fs/kcore: change copy_to_user to copy_in_user

On Thu, 20 Aug 2015 18:46:56 +0800 yalin wang <yalin.wang2010@...il.com> wrote:

> The copy_to_user() here expect can fix the fault on both kernel and
> user address, this is not true on other platforms except x86,
> change to user copy_in_user() so that can detect the source and
> destination address page fault, work as expected:
> 
> ...
>
> This is the x86 copy_to_user implementation, the fault instruction is
> label 1b, 3b, because movsb instruction will fault on both source and
> destination address, but on other platforms, like arm64 and arm:
> 
> ...
> 
> It only check the str instructions, means only check fault on destination
> address, if the source address in kernel is invalid, it will result in
> kernel panic(), this may happened in read_kcore() function, the
> kern_addr_valid() only make sure the address is valid during call it,
> when it returned, the kernel address may be invalid, like kunmap(),
> setfixmap(), vfree() function will change kernel pagetables, and there is
> not any sync between read_kcore() and kernel pagetable change. I change
> to use copy_in_user(), so that can check both source and destination address,
> avoid the kernel panic() in some unlucky circumstance.

This difference between x86 and the other architectures is problematic.
It creates risk that code which was tested on x86 will fail on other
architectures in rare situations.

Now, if I'm understanding things correctly, this situation is rare
because there aren't many places in which the kernel will access kernel
memory which can be concurrently unmapped.  

> ...
>
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -515,8 +515,12 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
>  		} else {
>  			if (kern_addr_valid(start)) {
>  				unsigned long n;
> -
> -				n = copy_to_user(buffer, (char *)start, tsz);
> +				if ((start + tsz < tsz) ||
> +						(start + tsz) > TASK_SIZE)
> +					return -EFAULT;
> +				set_fs(KERNEL_DS);
> +				n = copy_in_user(buffer, (char *)start, tsz);
> +				set_fs(USER_DS);
>  				/*
>  				 * We cannot distinguish between fault on source
>  				 * and fault on destination. When this happens

huh.  I seem to have forgotten that copy_in_user() exists.  It is of
course rigorously undocumented, but iirc it's there to copy from
userspace to userspace (copy_within_user would be a better name?)

And in this patch what you're doing is repurposing copy_in_user to mean
"copy from userspace to kernel memory which might be unmapped".

I'm not at all confident that this trick will work on all
architectures: code which is designed to handle a userspace fault is
now expected to correctly handle a kernel space fault?

--
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/