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, 13 Aug 2015 15:49:54 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	David Drysdale <drysdale@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Will Drewry <wad@...omium.org>, Ingo Molnar <mingo@...nel.org>,
	Alok Kataria <akataria@...are.com>,
	Borislav Petkov <bp@...en8.de>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>, X86 ML <x86@...nel.org>
Subject: Re: [Regression v4.2 ?] 32-bit seccomp-BPF returned errno values
 wrong in VM?

On Thu, Aug 13, 2015 at 2:47 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> It seems to me that the bug is that sysexit_from_sys_call isn't
> reloading RAX from regs->ax.

Ugh. That code is confusing, and _most_ cases seem to have %rax already loaded.

There seems to be three cases:

 - fallthrough from cstar_dispatch after a successful call to the system call

   This has %rax as the correct return value (which also got saved to
RAX on stack)

 - the 'auditsys_exit' macro 'exit' case.

   This seems to have %rax reloaded inside the macro

 - the out-of-range system call case for cstar_dispatch

   This does *not* seem to load %rax with $ENOSYS, but keeps the bad
system call number in it.

so yeah, there seems to be a bug there, but if I read it right, that
bug seems to happen just for the out-of-range system call case, which
afaik isn't the case reported here.

I guess adding a re-load of %rax is ok, even though in the common
cases it is already loaded.

Oh, and sysexit_from_sys_call seems to have the exact same situation.
The "system call dispatch with %rax out of range" fallthrough case
doesn't set %rax to ENOSYS.

So I guess we could remove the reloading of system call return value
from auditsys_exit, and just do it unconditionally in the common path.

Which is sad, since the *really* common case already has the right
value, but whatever.

Does the attached patch make sense and work? Totally untested, just
looking at the code. But maybe it's right, because it's exactly that
ENOSYS case that the bad patch in question changed.

Btw, the old ENOSYS code also cleared ORIG_EAX. I'm not sure why, but
we used to have

 ia32_badsys:
        movq $0,ORIG_RAX(%rsp)
        movq $-ENOSYS,%rax
        jmp ia32_sysret

for that case.

                   Linus

View attachment "patch.diff" of type "text/plain" (1084 bytes)

Powered by blists - more mailing lists