On Fri, Nov 15, 2024 at 02:52:07PM -0600, Gax-c wrote:
From: Zichen Xie zichenxie0106@gmail.com
raw_copy_from_user() do not call access_ok(), so this code allowed userspace to access any virtual memory address. Change it to copy_from_user().
How can you access *any* virtual memory address, given that we force the address to map userspace via __uaccess_mask_ptr()?
Fixes: 9e94fdade4d8 ("arm64: uaccess: simplify __copy_user_flushcache()")
I don't think that commit changed the semantics of the code, so if it's broken then I think it was broken before that change as well.
Signed-off-by: Zichen Xie zichenxie0106@gmail.com Cc: stable@vger.kernel.org
arch/arm64/lib/uaccess_flushcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/lib/uaccess_flushcache.c b/arch/arm64/lib/uaccess_flushcache.c index 7510d1a23124..fb138a3934db 100644 --- a/arch/arm64/lib/uaccess_flushcache.c +++ b/arch/arm64/lib/uaccess_flushcache.c @@ -24,7 +24,7 @@ unsigned long __copy_user_flushcache(void *to, const void __user *from, { unsigned long rc;
- rc = raw_copy_from_user(to, from, n);
- rc = copy_from_user(to, from, n);
Does anybody actually call this with an unchecked user address?
From a quick look, there are two callers of _copy_from_iter_flushcache():
1. pmem_recovery_write() - looks like it's using a kernel address?
2. dax_copy_from_iter() - has a comment saying the address was already checked in vfs_write().
What am I missing? It also looks like x86 elides the check.
Will