[PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
From: Linus Torvalds
commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 upstream.
Originally, the rule used to be that you'd have to do access_ok()
separately, and then user_access_begin() before actually doing the
direct (optimized) user access.
But experience has shown that people then decide not to do access_ok()
at all, and instead rely on it being implied by other operations or
similar. Which makes it very hard to verify that the access has
actually been range-checked.
If you use the unsafe direct user accesses, hardware features (either
SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged
Access Never - on ARM) do force you to use user_access_begin(). But
nothing really forces the range check.
By putting the range check into user_access_begin(), we actually force
people to do the right thing (tm), and the range check vill be visible
near the actual accesses. We have way too long a history of people
trying to avoid them.
Signed-off-by: Linus Torvalds
Signed-off-by: Ashwin H
---
arch/x86/include/asm/uaccess.h | 11 ++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +--
include/linux/uaccess.h| 2 +-
kernel/compat.c| 6 ++
kernel/exit.c | 6 ++
lib/strncpy_from_user.c| 9 +
lib/strnlen_user.c | 9 +
7 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 9718303..82cd874 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -711,7 +711,16 @@ extern struct movsl_mask {
* checking before using them, but you have to surround them with the
* user_access_begin/end() pair.
*/
-#define user_access_begin()__uaccess_begin()
+static __must_check inline bool user_access_begin(const bool type,
+ const void __user *ptr,
+ size_t len)
+{
+ if (unlikely(!access_ok(type, ptr, len)))
+ return 0;
+ __uaccess_begin();
+ return 1;
+}
+#define user_access_begin(t, a, b) user_access_begin(t, a, b)
#define user_access_end() __uaccess_end()
#define unsafe_put_user(x, ptr, err_label)
\
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f08c547..7110e8f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1604,7 +1604,9 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
* happened we would make the mistake of assuming that the
* relocations were valid.
*/
- user_access_begin();
+ if (!user_access_begin(VERIFY_WRITE, urelocs, size))
+ goto end_user;
+
for (copied = 0; copied < nreloc; copied++)
unsafe_put_user(-1,
&urelocs[copied].presumed_offset,
@@ -2649,7 +2651,16 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void
*data,
unsigned int i;
/* Copy the new buffer offsets back to the user's exec list. */
- user_access_begin();
+ /*
+* Note: count * sizeof(*user_exec_list) does not overflow,
+* because we checked 'count' in check_buffer_count().
+*
+* And this range already got effectively checked earlier
+* when we did the "copy_from_user()" above.
+*/
+ if (!user_access_begin(VERIFY_WRITE, user_exec_list, count *
sizeof(*user_exec_list)))
+ goto end_user;
+
for (i = 0; i < args->buffer_count; i++) {
if (!(exec2_list[i].offset & UPDATE))
continue;
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index efe79c1..d55b68b 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -267,7 +267,7 @@ extern long strncpy_from_unsafe(char *dst, const void
*unsafe_addr, long count);
probe_kernel_read(&retval, addr, sizeof(retval))
#ifndef user_access_begin
-#define user_access_begin() do { } while (0)
+#define user_access_begin(type, ptr, len) access_ok(type, ptr, len)
#define user_access_end() do { } while (0)
#define unsafe_get_user(x, ptr, err) do { if (unlikely(__get_user(x, ptr)))
goto err; } while (0)
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr)))
goto err; } while (0)
diff --git a/kernel/compat.c b/kernel/compat.c
index 8e40efc..e4548a9 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -354,10 +354,9 @@ long compat_get_bitmap(unsig
Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
This patch fixes CVE-2018-20669 in 4.19 tree. On 13/05/20, 11:36 AM, "Greg KH" wrote: On Wed, May 13, 2020 at 07:19:21AM +0530, ashwin-h wrote: > From: Linus Torvalds > > commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 upstream. > > Originally, the rule used to be that you'd have to do access_ok() > separately, and then user_access_begin() before actually doing the > direct (optimized) user access. > > But experience has shown that people then decide not to do access_ok() > at all, and instead rely on it being implied by other operations or > similar. Which makes it very hard to verify that the access has > actually been range-checked. > > If you use the unsafe direct user accesses, hardware features (either > SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged > Access Never - on ARM) do force you to use user_access_begin(). But > nothing really forces the range check. > > By putting the range check into user_access_begin(), we actually force > people to do the right thing (tm), and the range check vill be visible > near the actual accesses. We have way too long a history of people > trying to avoid them. > > Signed-off-by: Linus Torvalds > Signed-off-by: Ashwin H > --- > arch/x86/include/asm/uaccess.h | 11 ++- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +-- > include/linux/uaccess.h| 2 +- > kernel/compat.c| 6 ++ > kernel/exit.c | 6 ++ > lib/strncpy_from_user.c| 9 + > lib/strnlen_user.c | 9 + > 7 files changed, 38 insertions(+), 20 deletions(-) Are you wanting this merged to a specific stable kernel tree? If so, why? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
> Ok, but what does that mean for us? > > You need to say why you are sending a patch, otherwise we will guess wrong. In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does user_access_begin() without doing access_ok(Checks if a user space pointer is valid) first. A local attacker can craft a malicious ioctl function call to overwrite arbitrary kernel memory, resulting in a Denial of Service or privilege escalation (CVE-2018-20669) This patch makes sure that user_access_begin always does access_ok. user_access_begin has been modified to do access_ok internally. Thanks, Ashwin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
> -Original Message- > From: Greg KH > Sent: Wednesday, May 27, 2020 9:02 PM > To: Ashwin H > Cc: x...@kernel.org; dri-devel@lists.freedesktop.org; intel- > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org; > Srivatsa Bhat ; sriva...@csail.mit.edu; > rost...@goodmis.org; Steven Rostedt ; Linus > Torvalds > Subject: Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' > > On Wed, May 13, 2020 at 05:08:19PM +, Ashwin H wrote: > > > Ok, but what does that mean for us? > > > > > > You need to say why you are sending a patch, otherwise we will guess > wrong. > > > > In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does > user_access_begin() without doing access_ok(Checks if a user space pointer > is valid) first. > > A local attacker can craft a malicious ioctl function call to > > overwrite arbitrary kernel memory, resulting in a Denial of Service or > > privilege escalation (CVE-2018-20669) > > > > This patch makes sure that user_access_begin always does access_ok. > > user_access_begin has been modified to do access_ok internally. > > I had this in the tree, but it broke the build on alpha, sh, and maybe a few > others :( > Thanks Greg for including this patch. I am sorry that this patch caused the failure. As I see this is not a build failure but tests have failed. Build results: total: 155 pass: 155 fail: 0 Qemu test results: total: 421 pass: 390 fail: 31 Failed tests: > See: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F > %2Flore.kernel.org%2Fr%2F20200527140225.GA214763%40roeck- > us.net&data=02%7C01%7Cashwinh%40vmware.com%7Cd8f60bb8a4584 > 7caa10f08d802530997%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7 > C637261902960990057&sdata=Vjv9v0QhebfcOGSq1UUDKshTDA%2FOV > 4aKbqzKKJkEQxM%3D&reserved=0 > for the details. > > Can you dig out all of the needed follow-on patches as well, and send them > all as a patch series for 4.19.y so that I can queue them all up at once? > I will check for follow-on patches and get back. > thanks, > > greg k-h Thanks, Ashwin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
> -Original Message- > From: Ashwin H > Sent: Thursday, May 28, 2020 1:01 PM > To: Greg KH > Cc: x...@kernel.org; dri-devel@lists.freedesktop.org; intel- > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org; > Srivatsa Bhat ; sriva...@csail.mit.edu; > rost...@goodmis.org; Steven Rostedt ; Linus > Torvalds > Subject: RE: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' > > > > > -Original Message- > > From: Greg KH > > Sent: Wednesday, May 27, 2020 9:02 PM > > To: Ashwin H > > Cc: x...@kernel.org; dri-devel@lists.freedesktop.org; intel- > > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; > > sta...@kernel.org; Srivatsa Bhat ; > > sriva...@csail.mit.edu; rost...@goodmis.org; Steven Rostedt > > ; Linus Torvalds > > Subject: Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' > > > > On Wed, May 13, 2020 at 05:08:19PM +, Ashwin H wrote: > > > > Ok, but what does that mean for us? > > > > > > > > You need to say why you are sending a patch, otherwise we will > > > > guess > > wrong. > > > > > > In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does > > user_access_begin() without doing access_ok(Checks if a user space > > pointer is valid) first. > > > A local attacker can craft a malicious ioctl function call to > > > overwrite arbitrary kernel memory, resulting in a Denial of Service > > > or privilege escalation (CVE-2018-20669) > > > > > > This patch makes sure that user_access_begin always does access_ok. > > > user_access_begin has been modified to do access_ok internally. > > > > I had this in the tree, but it broke the build on alpha, sh, and maybe > > a few others :( > > > Thanks Greg for including this patch. > I am sorry that this patch caused the failure. As I see this is not a build > failure > but tests have failed. > Build results: > total: 155 pass: 155 fail: 0 > Qemu test results: > total: 421 pass: 390 fail: 31 > Failed tests: > > > > > > See: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F > > %2Flore.kernel.org%2Fr%2F20200527140225.GA214763%40roeck- > > > us.net&data=02%7C01%7Cashwinh%40vmware.com%7Cd8f60bb8a4584 > > > 7caa10f08d802530997%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7 > > > C637261902960990057&sdata=Vjv9v0QhebfcOGSq1UUDKshTDA%2FOV > > 4aKbqzKKJkEQxM%3D&reserved=0 > > for the details. > > > > Can you dig out all of the needed follow-on patches as well, and send > > them all as a patch series for 4.19.y so that I can queue them all up at > > once? > > > > I will check for follow-on patches and get back. This seems to be the issue in alpha and SH https://lore.kernel.org/lkml/6a4fe075-a644-1b06-305b-9e55b8c95...@roeck-us.net/#t alpha and SH had buggy implementation of access_ok Thanks, Ashwin > > > thanks, > > > > greg k-h > > Thanks, > Ashwin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
