linux-kernel - Re: [Regression v4.2 ?] 32-bit seccomp-BPF returned errno values wrong in VM?

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]

Message-ID: <CA+55aFyA9+16Jer2nKMOs6_uhRA-egvFDSR8fgNoD9AuPLE4GQ@mail.gmail.com>
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)