AC regions are special, make sure we don't do possibly complex
evaluations there.
Probably-Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
---
arch/x86/include/asm/uaccess.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -431,8 +431,10 @@ do { \
({ \
__label__ __pu_label; \
int __pu_err = -EFAULT; \
+ __typeof__(*(ptr)) __pu_val; \
+ __pu_val = x; \
__uaccess_begin(); \
- __put_user_size((x), (ptr), (size), __pu_label); \
+ __put_user_size(__pu_val, (ptr), (size), __pu_label); \
__pu_err = 0; \
__pu_label: \
__uaccess_end(); \
On Mon, Feb 25, 2019 at 4:53 AM Peter Zijlstra <[email protected]> wrote:
>
> AC regions are special, make sure we don't do possibly complex
> evaluations there.
>
> Probably-Signed-off-by: Andy Lutomirski <[email protected]>
I put a slightly fancier version here last night so that the 0day bot
could chew on it:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=b294da548d92320f194172272dda1f734e51013d
want to snarf it up? It's the same thing except that I added Linus'
suggested change, found the offending patch that broke it (hi Linus!)
and added a bit more changelog :)
On Mon, Feb 25, 2019 at 07:43:53AM -0800, Andy Lutomirski wrote:
> On Mon, Feb 25, 2019 at 4:53 AM Peter Zijlstra <[email protected]> wrote:
> >
> > AC regions are special, make sure we don't do possibly complex
> > evaluations there.
> >
> > Probably-Signed-off-by: Andy Lutomirski <[email protected]>
>
> I put a slightly fancier version here last night so that the 0day bot
> could chew on it:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=b294da548d92320f194172272dda1f734e51013d
>
> want to snarf it up? It's the same thing except that I added Linus'
> suggested change, found the offending patch that broke it (hi Linus!)
> and added a bit more changelog :)
Sure; I'll take that one.
On Mon, Feb 25, 2019 at 07:43:53AM -0800, Andy Lutomirski wrote:
> I put a slightly fancier version here last night so that the 0day bot
> could chew on it:
I'm guessing 0day bot didn't complain so far? Or should we give it one
more day?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Feb 25, 2019 at 8:37 AM Borislav Petkov <[email protected]> wrote:
>
> On Mon, Feb 25, 2019 at 07:43:53AM -0800, Andy Lutomirski wrote:
> > I put a slightly fancier version here last night so that the 0day bot
> > could chew on it:
>
> I'm guessing 0day bot didn't complain so far? Or should we give it one
> more day?
>
No complaints yet. I'll holler if it complains. This one patch could
plausibly be -stable or 5.0 material, I suppose.
Commit-ID: 1ee2bd5e09195d5476daefec5c64ba597a0a9920
Gitweb: https://git.kernel.org/tip/1ee2bd5e09195d5476daefec5c64ba597a0a9920
Author: Andy Lutomirski <[email protected]>
AuthorDate: Fri, 22 Feb 2019 17:17:04 -0800
Committer: Borislav Petkov <[email protected]>
CommitDate: Mon, 25 Feb 2019 18:55:04 +0100
x86/uaccess: Don't leak the AC flag into __put_user() value evaluation
When calling __put_user(foo(), ptr), the __put_user() macro would call
foo() in between __uaccess_begin() and __uaccess_end(). If that code
were buggy, then those bugs would be run without SMAP protection.
Fortunately, there seem to be few instances of the problem in the
kernel. Nevertheless, __put_user() should be fixed to avoid doing this.
Therefore, evaluate __put_user()'s argument before setting AC.
This issue was noticed when an objtool hack by Peter Zijlstra complained
about genregs_get() and I compared the assembly output to the C source.
[ bp: Massage commit message. ]
Fixes: 11f1a4b9755f ("x86: reorganize SMAP handling in user space accesses")
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
---
arch/x86/include/asm/uaccess.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index a77445d1b034..d7688efacf29 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -284,7 +284,7 @@ do { \
__put_user_goto(x, ptr, "l", "k", "ir", label); \
break; \
case 8: \
- __put_user_goto_u64((__typeof__(*ptr))(x), ptr, label); \
+ __put_user_goto_u64(x, ptr, label); \
break; \
default: \
__put_user_bad(); \
@@ -431,8 +431,10 @@ do { \
({ \
__label__ __pu_label; \
int __pu_err = -EFAULT; \
+ __typeof__(*(ptr)) __pu_val; \
+ __pu_val = x; \
__uaccess_begin(); \
- __put_user_size((x), (ptr), (size), __pu_label); \
+ __put_user_size(__pu_val, (ptr), (size), __pu_label); \
__pu_err = 0; \
__pu_label: \
__uaccess_end(); \
On Mon, Feb 25, 2019 at 7:44 AM Andy Lutomirski <[email protected]> wrote:
>
> I put a slightly fancier version here last night so that the 0day bot
> could chew on it:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=b294da548d92320f194172272dda1f734e51013d
Ack. Even if it does seem to get the whitespace wrong and not align things ;)
Linus
On Mon, Feb 25, 2019 at 11:09:53AM -0800, Linus Torvalds wrote:
> Ack. Even if it does seem to get the whitespace wrong and not align
> things ;)
It is the top commit so fixed up and added your ACK. :)
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Commit-ID: 2a418cf3f5f1caf911af288e978d61c9844b0695
Gitweb: https://git.kernel.org/tip/2a418cf3f5f1caf911af288e978d61c9844b0695
Author: Andy Lutomirski <[email protected]>
AuthorDate: Fri, 22 Feb 2019 17:17:04 -0800
Committer: Borislav Petkov <[email protected]>
CommitDate: Mon, 25 Feb 2019 20:17:05 +0100
x86/uaccess: Don't leak the AC flag into __put_user() value evaluation
When calling __put_user(foo(), ptr), the __put_user() macro would call
foo() in between __uaccess_begin() and __uaccess_end(). If that code
were buggy, then those bugs would be run without SMAP protection.
Fortunately, there seem to be few instances of the problem in the
kernel. Nevertheless, __put_user() should be fixed to avoid doing this.
Therefore, evaluate __put_user()'s argument before setting AC.
This issue was noticed when an objtool hack by Peter Zijlstra complained
about genregs_get() and I compared the assembly output to the C source.
[ bp: Massage commit message and fixed up whitespace. ]
Fixes: 11f1a4b9755f ("x86: reorganize SMAP handling in user space accesses")
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
---
arch/x86/include/asm/uaccess.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index a77445d1b034..28376aa2d053 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -284,7 +284,7 @@ do { \
__put_user_goto(x, ptr, "l", "k", "ir", label); \
break; \
case 8: \
- __put_user_goto_u64((__typeof__(*ptr))(x), ptr, label); \
+ __put_user_goto_u64(x, ptr, label); \
break; \
default: \
__put_user_bad(); \
@@ -431,8 +431,10 @@ do { \
({ \
__label__ __pu_label; \
int __pu_err = -EFAULT; \
+ __typeof__(*(ptr)) __pu_val; \
+ __pu_val = x; \
__uaccess_begin(); \
- __put_user_size((x), (ptr), (size), __pu_label); \
+ __put_user_size(__pu_val, (ptr), (size), __pu_label); \
__pu_err = 0; \
__pu_label: \
__uaccess_end(); \