Files
msm-5.15/include/linux
Dave Hansen 41d8b591d7 uaccess: Add speculation barrier to copy_from_user()
commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47 upstream.

The results of "access_ok()" can be mis-speculated.  The result is that
you can end speculatively:

	if (access_ok(from, size))
		// Right here

even for bad from/size combinations.  On first glance, it would be ideal
to just add a speculation barrier to "access_ok()" so that its results
can never be mis-speculated.

But there are lots of system calls just doing access_ok() via
"copy_to_user()" and friends (example: fstat() and friends).  Those are
generally not problematic because they do not _consume_ data from
userspace other than the pointer.  They are also very quick and common
system calls that should not be needlessly slowed down.

"copy_from_user()" on the other hand uses a user-controller pointer and
is frequently followed up with code that might affect caches.  Take
something like this:

	if (!copy_from_user(&kernelvar, uptr, size))
		do_something_with(kernelvar);

If userspace passes in an evil 'uptr' that *actually* points to a kernel
addresses, and then do_something_with() has cache (or other)
side-effects, it could allow userspace to infer kernel data values.

Add a barrier to the common copy_from_user() code to prevent
mis-speculated values which happen after the copy.

Also add a stub for architectures that do not define barrier_nospec().
This makes the macro usable in generic code.

Since the barrier is now usable in generic code, the x86 #ifdef in the
BPF code can also go away.

Reported-by: Jordy Zomer <jordyzomer@google.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>   # BPF bits
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-25 12:06:44 +01:00
..
2021-07-21 19:54:21 -07:00
2021-09-20 12:43:34 +01:00
2023-02-01 08:27:20 +01:00
2021-08-29 14:47:42 +03:00
2022-08-17 14:23:11 +02:00
2022-10-26 12:35:12 +02:00
2022-08-31 17:16:34 +02:00
2021-08-16 10:50:32 -06:00
2021-08-26 16:52:03 -07:00
2021-12-14 10:57:11 +01:00
2022-07-07 17:53:26 +02:00
2021-11-25 09:48:41 +01:00
2021-07-20 09:20:49 -07:00
2021-09-07 21:17:28 +02:00
2021-08-26 15:32:28 -04:00
2021-07-27 11:00:36 +02:00
2021-09-06 07:20:56 -04:00
2023-01-12 11:59:14 +01:00
2021-07-26 15:09:44 +02:00
2021-07-27 20:11:45 +01:00
2021-07-27 20:11:44 +01:00
2021-09-03 09:58:13 -07:00
2021-08-05 11:46:42 +01:00
2022-10-26 12:35:26 +02:00
2022-04-13 20:59:03 +02:00
2021-07-27 17:05:06 +01:00
2021-07-27 09:29:15 +02:00
2022-08-17 14:24:08 +02:00
2022-07-12 16:35:08 +02:00
2022-06-09 10:23:32 +02:00
2021-09-17 13:52:17 +01:00
2021-07-06 10:37:46 -05:00
2022-11-03 23:59:15 +09:00
2022-07-02 16:41:17 +02:00
2021-08-18 22:08:24 +02:00
2021-09-02 21:38:56 +02:00
2021-10-07 16:51:57 +02:00
2021-08-17 17:50:51 +02:00
2022-07-12 16:35:08 +02:00
2021-08-06 13:41:48 -07:00
2021-08-19 09:02:55 +09:00
2021-11-21 13:44:12 +01:00
2021-07-27 12:17:21 +02:00
2022-07-29 17:25:32 +02:00
2021-07-27 12:12:08 +02:00
2021-09-08 15:32:35 -07:00
2022-09-15 11:30:05 +02:00
2021-08-11 06:44:24 -04:00