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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMzpN2hgcRp=4TQSk4w64-ceC8G0uQo=QMyzvR_EUkWP7mwacA@mail.gmail.com>
Date:   Fri, 13 Oct 2017 19:49:43 -0400
From:   Brian Gerst <brgerst@...il.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>
Subject: Re: [RFC][PATCH] x86, syscalls: use SYSCALL_DEFINE() macros for sys_modify_ldt()

On Fri, Oct 13, 2017 at 5:03 PM, Andy Lutomirski <luto@...nel.org> wrote:
> On Fri, Oct 13, 2017 at 1:39 PM, Dave Hansen
> <dave.hansen@...ux.intel.com> wrote:
>>
>> I noticed that we don't have tracepoints for sys_modify_ldt().  I
>> think that's because we define it directly instead of using the
>> normal SYSCALL_DEFINEx() macros.
>>
>> Is there a reason for that, or were they just missed when the
>> macros were created?
>
> No, and it's a longstanding fsckup that I think you can't fix like
> this because...
>
>>
>> Cc: x86@...nel.org
>> Cc: Andy Lutomirski <luto@...nel.org>
>>
>> ---
>>
>>  b/arch/x86/include/asm/syscalls.h |    2 +-
>>  b/arch/x86/kernel/ldt.c           |    5 +++--
>>  b/arch/x86/um/ldt.c               |    3 ++-
>>  3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff -puN arch/x86/kernel/ldt.c~x86-syscall-macros-modify_ldt arch/x86/kernel/ldt.c
>> --- a/arch/x86/kernel/ldt.c~x86-syscall-macros-modify_ldt       2017-10-13 13:30:12.802553391 -0700
>> +++ b/arch/x86/kernel/ldt.c     2017-10-13 13:30:12.817553391 -0700
>> @@ -12,6 +12,7 @@
>>  #include <linux/string.h>
>>  #include <linux/mm.h>
>>  #include <linux/smp.h>
>> +#include <linux/syscalls.h>
>>  #include <linux/slab.h>
>>  #include <linux/vmalloc.h>
>>  #include <linux/uaccess.h>
>> @@ -294,8 +295,8 @@ out:
>>         return error;
>>  }
>>
>> -asmlinkage int sys_modify_ldt(int func, void __user *ptr,
>> -                             unsigned long bytecount)
>> +SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
>> +               unsigned long , bytecount)
>
> sys_modify_ldt() returns int, which is wrong, and it's visibly wrong
> to 64-bit user code.  So I think you need to make sure that the return
> value is cast to int in all cases.

I don't think there will be a problem here.  If 64-bit userspace
treats it as an int, it will truncate to 32-bit signed and all is
well.  If it is treating it as a long, then it's currently broken for
errors anyways.

--
Brian Gerst

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ