linux-kernel - Re: [Patch V3] x86/ldt: correct fpu emulation access to ldt

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Aug 2015 08:15:47 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Juergen Gross <jgross@...e.com>
Cc:	billm@...bpc.org.au, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Lutomirski <luto@...nel.org>,
	stable <stable@...r.kernel.org>
Subject: Re: [Patch V3] x86/ldt: correct fpu emulation access to ldt

On Thu, Aug 6, 2015 at 2:21 AM, Juergen Gross <jgross@...e.com> wrote:
> Commit 37868fe113ff ("x86/ldt: Make modify_ldt synchronous") introduced
> a new struct ldt_struct anchored at mm->context.ldt.
>
> Adapt the x86 fpu emulation to use that new structure.
>
> Cc: <stable@...r.kernel.org> # 37868fe113ff: x86/ldt: Make modify_ldt synchronous
> Cc: <stable@...r.kernel.org> # a5b9e5a2f14f: x86/ldt: Make modify_ldt optional
> Signed-off-by: Juergen Gross <jgross@...e.com>
> ---
>  arch/x86/math-emu/fpu_entry.c   |  3 +--
>  arch/x86/math-emu/fpu_system.h  | 21 ++++++++++++++++++---
>  arch/x86/math-emu/get_address.c |  3 +--
>  3 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/math-emu/fpu_entry.c b/arch/x86/math-emu/fpu_entry.c
> index f37e84a..203318a 100644
> --- a/arch/x86/math-emu/fpu_entry.c
> +++ b/arch/x86/math-emu/fpu_entry.c
> @@ -29,7 +29,6 @@
>
>  #include <asm/uaccess.h>
>  #include <asm/traps.h>
> -#include <asm/desc.h>
>  #include <asm/user.h>
>  #include <asm/fpu/internal.h>
>
> @@ -181,7 +180,7 @@ void math_emulate(struct math_emu_info *info)
>                         math_abort(FPU_info, SIGILL);
>                 }
>
> -               code_descriptor = LDT_DESCRIPTOR(FPU_CS);
> +               code_descriptor = *FPU_get_ldt_descriptor(FPU_CS);
>                 if (SEG_D_SIZE(code_descriptor)) {
>                         /* The above test may be wrong, the book is not clear */
>                         /* Segmented 32 bit protected mode */
> diff --git a/arch/x86/math-emu/fpu_system.h b/arch/x86/math-emu/fpu_system.h
> index 9ccecb6..d4a49d7 100644
> --- a/arch/x86/math-emu/fpu_system.h
> +++ b/arch/x86/math-emu/fpu_system.h
> @@ -16,9 +16,24 @@
>  #include <linux/kernel.h>
>  #include <linux/mm.h>
>
> -/* s is always from a cpu register, and the cpu does bounds checking
> - * during register load --> no further bounds checks needed */
> -#define LDT_DESCRIPTOR(s)      (((struct desc_struct *)current->mm->context.ldt)[(s) >> 3])
> +#include <asm/desc.h>
> +#include <asm/mmu_context.h>
> +
> +static inline struct desc_struct *FPU_get_ldt_descriptor(unsigned seg)
> +{
> +       static struct desc_struct zero_desc;
> +       struct desc_struct *ret = &zero_desc;
> +
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
> +       seg >>= 3;
> +       mutex_lock(&current->mm->context.lock);
> +       if (current->mm->context.ldt && seg < current->mm->context.ldt->size)
> +               ret = current->mm->context.ldt->entries + seg;
> +       mutex_unlock(&current->mm->context.lock);
> +#endif

Is there a good reason to return a pointer instead of returning struct
desc_struct directly?  I think that, if you return a pointer, the
locking is still wrong.  context.ldt can change at any point during
which IRQs are enabled (unless you hold the mutex), so I don't think
the mutex is sufficient -- the pointer can become invalid even after
this function returns.

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