Re: BUGreport: fix minor infoleak in get_user_ex()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Oct 27, 2016 at 03:32:10PM -0400, Joe Korty wrote:
> Hi Al,
> I don't know if this is worth fixing or not, but I thought
> I would mention it in case it was.
> 
> A git bisect search shows that the commit:
> 
>   commit 319fe11519401e8a5db191a0a93aa2c1d7bb59f4
>   Author: Al Viro <viro@ZenIV.linux.org.uk>
>   Date:   Thu Sep 15 02:35:29 2016 +0100
> 
> causes some malformed rt_sigqueueinfo syscalls, executed under
> x86_64 kernels running compat mode programs, to oops with
> the following message:
> 
> [   66.054786] BUG: unable to handle kernel paging request at 00000000020573eb
> [   66.061793] IP: [<00000000020573eb>] 0x20573eb
> [   66.066251] PGD 122263067 PUD 120a0c067 PMD 0 
> [   66.070745] Oops: 0010 [#1] PREEMPT SMP 
> [   66.074717] Modules linked in:
> [   66.077789] CPU: 7 PID: 5496 Comm: cc Not tainted 4.1.35 #1
> [   66.083365] Hardware name: Supermicro H8DM8-2/H8DM8-2, BIOS 080014  10/22/2009
> [   66.090582] task: ffff88006b044400 ti: ffff88006b300000 task.ti: ffff88006b300000
> [   66.098067] RIP: 0010:[<00000000020573eb>]  [<00000000020573eb>] 0x20573eb
> [   66.104961] RSP: 0018:ffff88006b303e98  EFLAGS: 00010246
> [   66.110269] RAX: 00007fffffffef80 RBX: 0000000000000000 RCX: 0000000000000000
> [   66.117399] RDX: ffff88006b304000 RSI: 0000000000000000 RDI: ffff88006b303ea8
> [   66.124528] RBP: ffff88006b303e98 R08: 0000000000000000 R09: 0000000000000000
> [   66.131667] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> [   66.138805] R13: ffff88006b303ea8 R14: 0000000000000000 R15: 0000000000000000
> [   66.145935] FS:  00007ffff7fca740(0000) GS:ffff880127d80000(0063) knlGS:00000000f7df06c0
> [   66.154027] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> [   66.159777] CR2: 00000000020573eb CR3: 000000011f874000 CR4: 00000000000006e0
> [   66.166906] Stack:
> [   66.168919]  ffff88006b303f48 ffffffff8107c4b5 0000000000000000 0000000000000000
> [   66.176403]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [   66.183872]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [   66.191341] Call Trace:
> [   66.193802]  [<ffffffff8107c4b5>] compat_SyS_rt_sigqueueinfo+0x45/0x70
> [   66.200340]  [<ffffffff8205648c>] cstar_dispatch+0x7/0x2a
> [   66.205755] Code:  Bad RIP value.
> [   66.209103] RIP  [<00000000020573eb>] 0x20573eb
> [   66.213648]  RSP <ffff88006b303e98>
> [   66.217134] CR2: 00000000020573eb
> [   66.220505] ---[ end trace 4f88266d7fd7e6d7 ]---
 
> The following test program can be used to trigger the problem:
> 
> /* gcc -m32 c.c -o c */
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <errno.h>
> #include <sys/syscall.h>
> 
> #define rt_sigqueueinfo 178
> 
> int main(int argc, char **argv) {
>      int stat = syscall(rt_sigqueueinfo, 0, 0, 0, 0, 0, 0);
>      printf("syscall(%d): stat: %d, errno: %d\n",
> 	     rt_sigqueueinfo, stat, errno);
>      return 0;
> }
> 
> This is under 4.1.35 on x86_64.

AFAICS, it steps on _ASM_EXTABLE_EX being more brittle in 4.1 - it pretty
much has to have the handler on the next insn after the faulting one, or
the resulting extable entry won't be recognized.  This
"x86/mm: Expand the exception table logic to allow new handling options"
in mainline is where that requirement has disappeared.  I think we
ought to use the plain _ASM_EXTABLE and just call something that would
set current_thread_info()->uaccess_err directly from the fixup code there.
That, or backport the commit switching to less brittle extables.