Re: fs: GPF in bd_mount

2016-09-05 Thread Dmitry Vyukov 
On Sun, Sep 4, 2016 at 4:29 PM, Al Viro  wrote:
> On Sun, Sep 04, 2016 at 03:06:06PM +0100, Al Viro wrote:
>
>> Said that, I'm not sure why mount_pseudo() would be returning any errors;
>> rejection should happen in the caller (due to MS_NOUSER in the flags), but
>> I don't understand what would trigger it on mount_pseudo() level...
>
> I see what's going on, but I wonder if sget() is the right place for userns
> checks...


FWIW, the upstream patch fixes the crash for me.

Do I understand it correctly that there is no perfect branch for such
testing (testing that aims at catching regressions asap and not
reporting what's already fixed)? Both mainline and linux-next miss
some fixes and functionality that is present on the other branch,
right?

Re: fs: GPF in bd_mount

2016-09-05 Thread Dmitry Vyukov 
On Sun, Sep 4, 2016 at 4:29 PM, Al Viro  wrote:
> On Sun, Sep 04, 2016 at 03:06:06PM +0100, Al Viro wrote:
>
>> Said that, I'm not sure why mount_pseudo() would be returning any errors;
>> rejection should happen in the caller (due to MS_NOUSER in the flags), but
>> I don't understand what would trigger it on mount_pseudo() level...
>
> I see what's going on, but I wonder if sget() is the right place for userns
> checks...


FWIW, the upstream patch fixes the crash for me.

Do I understand it correctly that there is no perfect branch for such
testing (testing that aims at catching regressions asap and not
reporting what's already fixed)? Both mainline and linux-next miss
some fixes and functionality that is present on the other branch,
right?

Re: fs: GPF in bd_mount

2016-09-04 Thread Al Viro 
On Sun, Sep 04, 2016 at 12:43:28PM +0200, Dmitry Vyukov wrote:

AFAICS, it's been introduced in commit 3684aa7099e0ab1038a1a1bf717ae60ffc3018d1
Author: Shaohua Li 
Date:   Mon Feb 22 15:27:40 2016 -0700

block-dev: enable writeback cgroup support

See if you can reproduce it after the following:

ed fs/block_dev.c <<'EOF'
/bd_mount/
/if/s/dent/!IS_ERR(dent)/
wq
EOF

Said that, I'm not sure why mount_pseudo() would be returning any errors;
rejection should happen in the caller (due to MS_NOUSER in the flags), but
I don't understand what would trigger it on mount_pseudo() level...

Re: fs: GPF in bd_mount

2016-09-04 Thread Al Viro 
On Sun, Sep 04, 2016 at 12:43:28PM +0200, Dmitry Vyukov wrote:

AFAICS, it's been introduced in commit 3684aa7099e0ab1038a1a1bf717ae60ffc3018d1
Author: Shaohua Li 
Date:   Mon Feb 22 15:27:40 2016 -0700

block-dev: enable writeback cgroup support

See if you can reproduce it after the following:

ed fs/block_dev.c <<'EOF'
/bd_mount/
/if/s/dent/!IS_ERR(dent)/
wq
EOF

Said that, I'm not sure why mount_pseudo() would be returning any errors;
rejection should happen in the caller (due to MS_NOUSER in the flags), but
I don't understand what would trigger it on mount_pseudo() level...

Re: fs: GPF in bd_mount

2016-09-04 Thread Al Viro 
On Sun, Sep 04, 2016 at 03:06:06PM +0100, Al Viro wrote:

> Said that, I'm not sure why mount_pseudo() would be returning any errors;
> rejection should happen in the caller (due to MS_NOUSER in the flags), but
> I don't understand what would trigger it on mount_pseudo() level...

I see what's going on, but I wonder if sget() is the right place for userns
checks...

Re: fs: GPF in bd_mount

2016-09-04 Thread Al Viro 
On Sun, Sep 04, 2016 at 03:06:06PM +0100, Al Viro wrote:

> Said that, I'm not sure why mount_pseudo() would be returning any errors;
> rejection should happen in the caller (due to MS_NOUSER in the flags), but
> I don't understand what would trigger it on mount_pseudo() level...

I see what's going on, but I wonder if sget() is the right place for userns
checks...

Re: fs: GPF in bd_mount

2016-09-04 Thread Mateusz Guzik 
On Sun, Sep 04, 2016 at 12:43:28PM +0200, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers GPF in bd_mount:
> 
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main()
> {
>   int fd;
> 
>   unshare(CLONE_NEWUSER);
>   unshare(CLONE_NEWNS);
>   mkdir("./bus", 0662515705056234013740);
>   mount("./bus/bus", "./bus", "bdev", 0,
>   "\xa9\x95\xbd\x88\x07\x6a\x39\xe8\xf4\xef\xf2\x6b\x88\x53\x1d\xdb"
>   "\xd2\x83\xf9\x5f\x4f\x44\x71\xf2\x08\x84\x2b\xae\x94\x87\xb7\xa6"
>   "\xf8\x9d\xc9\x96\xc7\x17\x2e\x22\xc4\xd2\xcc\xf9\x04\x0b\xd2\xaf"
>   "\xf3\x0b\xec\xeb\x2b\x75\xf2\x93\xa2\xd4\x00\xd8\x69\x47\x48\xf5"
>   "\xaf\x2b\xb8\x7c\x06\x04\x69\x8b\x46\x0d\x44\x79\x8c\x86\x68\xfd"
>   "\xd3\xb4\x1c\x8e\x9e\x6c\x58\x0c\xa5\xdf\x55\x4d\x59\x65\xc9\x70"
>   "\x7c\x8a\x44\x26\x7d\xba\xf0\x3d\x46\x9e\x3c\xbe\x22\xc3");
>   return 0;
> }
> 
> 
> general protection fault:  [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 2 PID: 4052 Comm: a.out Not tainted 4.8.0-rc3-next-20160825+ #11
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88006b37a380 task.stack: 880066dc
> RIP: 0010:[]  []
> bd_mount+0x52/0xa0 fs/block_dev.c:650
> RSP: 0018:880066dc7ca0  EFLAGS: 00010207
> RAX: dc00 RBX:  RCX: 0001
> RDX: 0018 RSI: 886fd6c0 RDI: 00c7
> RBP: 880066dc7cb0 R08: 88006b642cb8 R09: 
> R10:  R11:  R12: 8880d440
> R13: 88006a4ac1c0 R14: 88006b64b000 R15: 
> FS:  012b2880() GS:88006d20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 004b2160 CR3: 6cc72000 CR4: 06e0
> Stack:
>  880068e2c840 8880d440 880066dc7cf0 8186e73b
>  0004 88006659c600 8880d440 88006a4ac1c0
>   880068e2c840 880066dc7d40 818ce44a
> Call Trace:
>  [] mount_fs+0x9b/0x2f0 fs/super.c:1177
>  [] vfs_kern_mount+0x7a/0x3e0 fs/namespace.c:948
>  [< inline >] do_new_mount fs/namespace.c:2393
>  [] do_mount+0x3d5/0x26b0 fs/namespace.c:2715
>  [< inline >] SYSC_mount fs/namespace.c:2907
>  [] SyS_mount+0xab/0x120 fs/namespace.c:2884
>  [] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
>  [] entry_SYSCALL64_slow_path+0x25/0x25
> arch/x86/entry/entry_64.S:249
> Code: 87 e8 f3 ca fb ff 48 85 c0 48 89 c3 74 4c e8 a6 47 ca ff 48 8d
> bb c8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
> 3c 02 00 75 36 4c 8b a3 c8 00 00 00 48 b8 00 00 00 00 00 fc
> RIP  [] bd_mount+0x52/0xa0 fs/block_dev.c:650
>  RSP 
> ---[ end trace 0e5d909159d79633 ]---
> 
> 
> On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


I think this is fixed with:
commit e9e5e3fae8da7e237049e00e0bfc9e32fd808fe8
Author: Vegard Nossum 
Date:   Mon Aug 22 12:47:43 2016 +0200

bdev: fix NULL pointer dereference

in mainline. The commit is absent in linux-next.

-- 
Mateusz Guzik

Re: fs: GPF in bd_mount

2016-09-04 Thread Mateusz Guzik 
On Sun, Sep 04, 2016 at 12:43:28PM +0200, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers GPF in bd_mount:
> 
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main()
> {
>   int fd;
> 
>   unshare(CLONE_NEWUSER);
>   unshare(CLONE_NEWNS);
>   mkdir("./bus", 0662515705056234013740);
>   mount("./bus/bus", "./bus", "bdev", 0,
>   "\xa9\x95\xbd\x88\x07\x6a\x39\xe8\xf4\xef\xf2\x6b\x88\x53\x1d\xdb"
>   "\xd2\x83\xf9\x5f\x4f\x44\x71\xf2\x08\x84\x2b\xae\x94\x87\xb7\xa6"
>   "\xf8\x9d\xc9\x96\xc7\x17\x2e\x22\xc4\xd2\xcc\xf9\x04\x0b\xd2\xaf"
>   "\xf3\x0b\xec\xeb\x2b\x75\xf2\x93\xa2\xd4\x00\xd8\x69\x47\x48\xf5"
>   "\xaf\x2b\xb8\x7c\x06\x04\x69\x8b\x46\x0d\x44\x79\x8c\x86\x68\xfd"
>   "\xd3\xb4\x1c\x8e\x9e\x6c\x58\x0c\xa5\xdf\x55\x4d\x59\x65\xc9\x70"
>   "\x7c\x8a\x44\x26\x7d\xba\xf0\x3d\x46\x9e\x3c\xbe\x22\xc3");
>   return 0;
> }
> 
> 
> general protection fault:  [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 2 PID: 4052 Comm: a.out Not tainted 4.8.0-rc3-next-20160825+ #11
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88006b37a380 task.stack: 880066dc
> RIP: 0010:[]  []
> bd_mount+0x52/0xa0 fs/block_dev.c:650
> RSP: 0018:880066dc7ca0  EFLAGS: 00010207
> RAX: dc00 RBX:  RCX: 0001
> RDX: 0018 RSI: 886fd6c0 RDI: 00c7
> RBP: 880066dc7cb0 R08: 88006b642cb8 R09: 
> R10:  R11:  R12: 8880d440
> R13: 88006a4ac1c0 R14: 88006b64b000 R15: 
> FS:  012b2880() GS:88006d20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 004b2160 CR3: 6cc72000 CR4: 06e0
> Stack:
>  880068e2c840 8880d440 880066dc7cf0 8186e73b
>  0004 88006659c600 8880d440 88006a4ac1c0
>   880068e2c840 880066dc7d40 818ce44a
> Call Trace:
>  [] mount_fs+0x9b/0x2f0 fs/super.c:1177
>  [] vfs_kern_mount+0x7a/0x3e0 fs/namespace.c:948
>  [< inline >] do_new_mount fs/namespace.c:2393
>  [] do_mount+0x3d5/0x26b0 fs/namespace.c:2715
>  [< inline >] SYSC_mount fs/namespace.c:2907
>  [] SyS_mount+0xab/0x120 fs/namespace.c:2884
>  [] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
>  [] entry_SYSCALL64_slow_path+0x25/0x25
> arch/x86/entry/entry_64.S:249
> Code: 87 e8 f3 ca fb ff 48 85 c0 48 89 c3 74 4c e8 a6 47 ca ff 48 8d
> bb c8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
> 3c 02 00 75 36 4c 8b a3 c8 00 00 00 48 b8 00 00 00 00 00 fc
> RIP  [] bd_mount+0x52/0xa0 fs/block_dev.c:650
>  RSP 
> ---[ end trace 0e5d909159d79633 ]---
> 
> 
> On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


I think this is fixed with:
commit e9e5e3fae8da7e237049e00e0bfc9e32fd808fe8
Author: Vegard Nossum 
Date:   Mon Aug 22 12:47:43 2016 +0200

bdev: fix NULL pointer dereference

in mainline. The commit is absent in linux-next.

-- 
Mateusz Guzik

fs: GPF in bd_mount

2016-09-04 Thread Dmitry Vyukov 
Hello,

The following program triggers GPF in bd_mount:


// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
  int fd;

  unshare(CLONE_NEWUSER);
  unshare(CLONE_NEWNS);
  mkdir("./bus", 0662515705056234013740);
  mount("./bus/bus", "./bus", "bdev", 0,
  "\xa9\x95\xbd\x88\x07\x6a\x39\xe8\xf4\xef\xf2\x6b\x88\x53\x1d\xdb"
  "\xd2\x83\xf9\x5f\x4f\x44\x71\xf2\x08\x84\x2b\xae\x94\x87\xb7\xa6"
  "\xf8\x9d\xc9\x96\xc7\x17\x2e\x22\xc4\xd2\xcc\xf9\x04\x0b\xd2\xaf"
  "\xf3\x0b\xec\xeb\x2b\x75\xf2\x93\xa2\xd4\x00\xd8\x69\x47\x48\xf5"
  "\xaf\x2b\xb8\x7c\x06\x04\x69\x8b\x46\x0d\x44\x79\x8c\x86\x68\xfd"
  "\xd3\xb4\x1c\x8e\x9e\x6c\x58\x0c\xa5\xdf\x55\x4d\x59\x65\xc9\x70"
  "\x7c\x8a\x44\x26\x7d\xba\xf0\x3d\x46\x9e\x3c\xbe\x22\xc3");
  return 0;
}


general protection fault:  [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 2 PID: 4052 Comm: a.out Not tainted 4.8.0-rc3-next-20160825+ #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006b37a380 task.stack: 880066dc
RIP: 0010:[]  []
bd_mount+0x52/0xa0 fs/block_dev.c:650
RSP: 0018:880066dc7ca0  EFLAGS: 00010207
RAX: dc00 RBX:  RCX: 0001
RDX: 0018 RSI: 886fd6c0 RDI: 00c7
RBP: 880066dc7cb0 R08: 88006b642cb8 R09: 
R10:  R11:  R12: 8880d440
R13: 88006a4ac1c0 R14: 88006b64b000 R15: 
FS:  012b2880() GS:88006d20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004b2160 CR3: 6cc72000 CR4: 06e0
Stack:
 880068e2c840 8880d440 880066dc7cf0 8186e73b
 0004 88006659c600 8880d440 88006a4ac1c0
  880068e2c840 880066dc7d40 818ce44a
Call Trace:
 [] mount_fs+0x9b/0x2f0 fs/super.c:1177
 [] vfs_kern_mount+0x7a/0x3e0 fs/namespace.c:948
 [< inline >] do_new_mount fs/namespace.c:2393
 [] do_mount+0x3d5/0x26b0 fs/namespace.c:2715
 [< inline >] SYSC_mount fs/namespace.c:2907
 [] SyS_mount+0xab/0x120 fs/namespace.c:2884
 [] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
 [] entry_SYSCALL64_slow_path+0x25/0x25
arch/x86/entry/entry_64.S:249
Code: 87 e8 f3 ca fb ff 48 85 c0 48 89 c3 74 4c e8 a6 47 ca ff 48 8d
bb c8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 36 4c 8b a3 c8 00 00 00 48 b8 00 00 00 00 00 fc
RIP  [] bd_mount+0x52/0xa0 fs/block_dev.c:650
 RSP 
---[ end trace 0e5d909159d79633 ]---


On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.

fs: GPF in bd_mount

2016-09-04 Thread Dmitry Vyukov 
Hello,

The following program triggers GPF in bd_mount:


// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
  int fd;

  unshare(CLONE_NEWUSER);
  unshare(CLONE_NEWNS);
  mkdir("./bus", 0662515705056234013740);
  mount("./bus/bus", "./bus", "bdev", 0,
  "\xa9\x95\xbd\x88\x07\x6a\x39\xe8\xf4\xef\xf2\x6b\x88\x53\x1d\xdb"
  "\xd2\x83\xf9\x5f\x4f\x44\x71\xf2\x08\x84\x2b\xae\x94\x87\xb7\xa6"
  "\xf8\x9d\xc9\x96\xc7\x17\x2e\x22\xc4\xd2\xcc\xf9\x04\x0b\xd2\xaf"
  "\xf3\x0b\xec\xeb\x2b\x75\xf2\x93\xa2\xd4\x00\xd8\x69\x47\x48\xf5"
  "\xaf\x2b\xb8\x7c\x06\x04\x69\x8b\x46\x0d\x44\x79\x8c\x86\x68\xfd"
  "\xd3\xb4\x1c\x8e\x9e\x6c\x58\x0c\xa5\xdf\x55\x4d\x59\x65\xc9\x70"
  "\x7c\x8a\x44\x26\x7d\xba\xf0\x3d\x46\x9e\x3c\xbe\x22\xc3");
  return 0;
}


general protection fault:  [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 2 PID: 4052 Comm: a.out Not tainted 4.8.0-rc3-next-20160825+ #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006b37a380 task.stack: 880066dc
RIP: 0010:[]  []
bd_mount+0x52/0xa0 fs/block_dev.c:650
RSP: 0018:880066dc7ca0  EFLAGS: 00010207
RAX: dc00 RBX:  RCX: 0001
RDX: 0018 RSI: 886fd6c0 RDI: 00c7
RBP: 880066dc7cb0 R08: 88006b642cb8 R09: 
R10:  R11:  R12: 8880d440
R13: 88006a4ac1c0 R14: 88006b64b000 R15: 
FS:  012b2880() GS:88006d20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004b2160 CR3: 6cc72000 CR4: 06e0
Stack:
 880068e2c840 8880d440 880066dc7cf0 8186e73b
 0004 88006659c600 8880d440 88006a4ac1c0
  880068e2c840 880066dc7d40 818ce44a
Call Trace:
 [] mount_fs+0x9b/0x2f0 fs/super.c:1177
 [] vfs_kern_mount+0x7a/0x3e0 fs/namespace.c:948
 [< inline >] do_new_mount fs/namespace.c:2393
 [] do_mount+0x3d5/0x26b0 fs/namespace.c:2715
 [< inline >] SYSC_mount fs/namespace.c:2907
 [] SyS_mount+0xab/0x120 fs/namespace.c:2884
 [] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
 [] entry_SYSCALL64_slow_path+0x25/0x25
arch/x86/entry/entry_64.S:249
Code: 87 e8 f3 ca fb ff 48 85 c0 48 89 c3 74 4c e8 a6 47 ca ff 48 8d
bb c8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 36 4c 8b a3 c8 00 00 00 48 b8 00 00 00 00 00 fc
RIP  [] bd_mount+0x52/0xa0 fs/block_dev.c:650
 RSP 
---[ end trace 0e5d909159d79633 ]---


On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.