public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* null dereference in binfmt misc
@ 2017-10-09 21:19 Tycho Andersen
  2017-10-10  6:49 ` Santosh Sivaraj
  2017-10-10 11:16 ` Oleg Nesterov
  0 siblings, 2 replies; 4+ messages in thread
From: Tycho Andersen @ 2017-10-09 21:19 UTC (permalink / raw)
  To: Oleg Nesterov; +Cc: Kees Cook, linux-kernel

Hi,

It looks like eb23aa031 ("exec: binfmt_misc: remove the confusing
e->interp_file != NULL checks") uncovered a bug for me (see the trace below,
which I'm afraid isn't very helpful).

I have a fairly reliable reproducer, but before I dig in, I figured I'd ping
and see if anyone has any pointers on where to look.

Cheers,

Tycho

Oct  9 20:46:06 criu kernel: [   35.418432] BUG: unable to handle kernel NULL pointer dereference at 0000000000000013
Oct  9 20:46:06 criu kernel: [   35.419751] IP: bm_evict_inode+0x11/0x40
Oct  9 20:46:06 criu kernel: [   35.420361] PGD 0 P4D 0
Oct  9 20:46:06 criu kernel: [   35.420763] Oops: 0000 [#1] SMP
Oct  9 20:46:06 criu kernel: [   35.421258] Modules linked in: xt_mark fuse
Oct  9 20:46:06 criu kernel: [   35.421957] CPU: 3 PID: 1902 Comm: zdtm_ct Not tainted 4.14.0-rc4+ #35
Oct  9 20:46:06 criu kernel: [   35.422963] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
Oct  9 20:46:06 criu kernel: [   35.424356] task: ffff880133093200 task.stack: ffffc90000abc000
Oct  9 20:46:06 criu kernel: [   35.425312] RIP: 0010:bm_evict_inode+0x11/0x40
Oct  9 20:46:06 criu kernel: [   35.426003] RSP: 0018:ffffc90000abfc58 EFLAGS: 00010282
Oct  9 20:46:06 criu kernel: [   35.426813] RAX: ffffffff81211740 RBX: 0000000000000000 RCX: 0000000000000000
Oct  9 20:46:06 criu kernel: [   35.427916] RDX: 0000000000000001 RSI: 000000000000006b RDI: ffff880129955240
Oct  9 20:46:06 criu kernel: [   35.429012] RBP: ffffc90000abfc68 R08: ffff8801344ba330 R09: 00000001820001c5
Oct  9 20:46:06 criu kernel: [   35.430147] R10: ffffc90000abfdd0 R11: 0000000000001300 R12: ffff880129955240
Oct  9 20:46:06 criu kernel: [   35.431242] R13: ffffffff81820fa0 R14: ffff8801299552c8 R15: ffff8801299e6958
Oct  9 20:46:06 criu kernel: [   35.432345] FS:  00007f69f2b03700(0000) GS:ffff880139d80000(0000) knlGS:0000000000000000
Oct  9 20:46:06 criu kernel: [   35.433621] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct  9 20:46:06 criu kernel: [   35.434505] CR2: 0000000000000013 CR3: 0000000129220000 CR4: 00000000000006e0
Oct  9 20:46:06 criu kernel: [   35.435619] Call Trace:
Oct  9 20:46:06 criu kernel: [   35.435998]  evict+0xc2/0x190
Oct  9 20:46:06 criu kernel: [   35.436450]  iput+0x1de/0x230
Oct  9 20:46:06 criu kernel: [   35.436901]  dentry_unlink_inode+0xbd/0x160
Oct  9 20:46:06 criu kernel: [   35.437562]  __dentry_kill+0xba/0x160
Oct  9 20:46:06 criu kernel: [   35.438114]  shrink_dentry_list+0x114/0x2f0
Oct  9 20:46:06 criu kernel: [   35.438739]  shrink_dcache_parent+0x25/0x80
Oct  9 20:46:06 criu kernel: [   35.439365]  do_one_tree+0xd/0x50
Oct  9 20:46:06 criu kernel: [   35.439874]  shrink_dcache_for_umount+0x28/0x80
Oct  9 20:46:06 criu kernel: [   35.440551]  generic_shutdown_super+0x1a/0x110
Oct  9 20:46:06 criu kernel: [   35.441252]  kill_litter_super+0x24/0x40
Oct  9 20:46:06 criu kernel: [   35.441867]  deactivate_locked_super+0x39/0x70
Oct  9 20:46:06 criu kernel: [   35.442531]  deactivate_super+0x49/0x50
Oct  9 20:46:06 criu kernel: [   35.443105]  cleanup_mnt+0x3a/0x70
Oct  9 20:46:06 criu kernel: [   35.443626]  __cleanup_mnt+0xd/0x10
Oct  9 20:46:06 criu kernel: [   35.444151]  task_work_run+0x9a/0xd0
Oct  9 20:46:06 criu kernel: [   35.444690]  do_exit+0x313/0xc10
Oct  9 20:46:06 criu kernel: [   35.445215]  do_group_exit+0x42/0xc0
Oct  9 20:46:06 criu kernel: [   35.445751]  SyS_exit_group+0xf/0x10
Oct  9 20:46:06 criu kernel: [   35.446289]  entry_SYSCALL_64_fastpath+0x1a/0xa5
Oct  9 20:46:06 criu kernel: [   35.446979] RIP: 0033:0x7f69f25ed748
Oct  9 20:46:06 criu kernel: [   35.447530] RSP: 002b:00007fffc9953b08 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
Oct  9 20:46:06 criu kernel: [   35.448611] RAX: ffffffffffffffda RBX: 00007f69f28e6540 RCX: 00007f69f25ed748
Oct  9 20:46:06 criu kernel: [   35.449667] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
Oct  9 20:46:06 criu kernel: [   35.450678] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff98
Oct  9 20:46:06 criu kernel: [   35.451696] R10: 00007fffc9953a58 R11: 0000000000000246 R12: 00007f69f2b03700
Oct  9 20:46:06 criu kernel: [   35.452745] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Oct  9 20:46:06 criu kernel: [   35.453761] Code: 2f fd ff 85 c0 75 08 48 c7 43 30 a0 0f 82 81 5b 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 48 8b 9f 38 02 00 00 49 89 fc <f6> 43 13 10 74 0b 48 8b 7b 48 31 f6 e8 9e 58 fa ff 4c 89 e7 e8
Oct  9 20:46:06 criu kernel: [   35.456484] RIP: bm_evict_inode+0x11/0x40 RSP: ffffc90000abfc58
Oct  9 20:46:06 criu kernel: [   35.457326] CR2: 0000000000000013
Oct  9 20:46:06 criu kernel: [   35.457807] ---[ end trace 773951adf548e79e ]---

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: null dereference in binfmt misc
  2017-10-09 21:19 null dereference in binfmt misc Tycho Andersen
@ 2017-10-10  6:49 ` Santosh Sivaraj
  2017-10-10 11:16 ` Oleg Nesterov
  1 sibling, 0 replies; 4+ messages in thread
From: Santosh Sivaraj @ 2017-10-10  6:49 UTC (permalink / raw)
  To: Tycho Andersen; +Cc: Oleg Nesterov, Kees Cook, linux-kernel, chandan

* Tycho Andersen <tycho@tycho.ws> wrote (on 2017-10-09 21:19:40 +0000):

> Hi,
> 
> It looks like eb23aa031 ("exec: binfmt_misc: remove the confusing
> e->interp_file != NULL checks") uncovered a bug for me (see the trace below,
> which I'm afraid isn't very helpful).
>

I too can reproduce this issue. From 4.14-rc3 the panic happens during every
reboot.

Thanks,
Santosh

> I have a fairly reliable reproducer, but before I dig in, I figured I'd ping
> and see if anyone has any pointers on where to look.
> 
> Cheers,
> 
> Tycho
> 
> Oct  9 20:46:06 criu kernel: [   35.418432] BUG: unable to handle kernel NULL pointer dereference at 0000000000000013
> Oct  9 20:46:06 criu kernel: [   35.419751] IP: bm_evict_inode+0x11/0x40
> Oct  9 20:46:06 criu kernel: [   35.420361] PGD 0 P4D 0
> Oct  9 20:46:06 criu kernel: [   35.420763] Oops: 0000 [#1] SMP
> Oct  9 20:46:06 criu kernel: [   35.421258] Modules linked in: xt_mark fuse
> Oct  9 20:46:06 criu kernel: [   35.421957] CPU: 3 PID: 1902 Comm: zdtm_ct Not tainted 4.14.0-rc4+ #35
> Oct  9 20:46:06 criu kernel: [   35.422963] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
> Oct  9 20:46:06 criu kernel: [   35.424356] task: ffff880133093200 task.stack: ffffc90000abc000
> Oct  9 20:46:06 criu kernel: [   35.425312] RIP: 0010:bm_evict_inode+0x11/0x40
> Oct  9 20:46:06 criu kernel: [   35.426003] RSP: 0018:ffffc90000abfc58 EFLAGS: 00010282
> Oct  9 20:46:06 criu kernel: [   35.426813] RAX: ffffffff81211740 RBX: 0000000000000000 RCX: 0000000000000000
> Oct  9 20:46:06 criu kernel: [   35.427916] RDX: 0000000000000001 RSI: 000000000000006b RDI: ffff880129955240
> Oct  9 20:46:06 criu kernel: [   35.429012] RBP: ffffc90000abfc68 R08: ffff8801344ba330 R09: 00000001820001c5
> Oct  9 20:46:06 criu kernel: [   35.430147] R10: ffffc90000abfdd0 R11: 0000000000001300 R12: ffff880129955240
> Oct  9 20:46:06 criu kernel: [   35.431242] R13: ffffffff81820fa0 R14: ffff8801299552c8 R15: ffff8801299e6958
> Oct  9 20:46:06 criu kernel: [   35.432345] FS:  00007f69f2b03700(0000) GS:ffff880139d80000(0000) knlGS:0000000000000000
> Oct  9 20:46:06 criu kernel: [   35.433621] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Oct  9 20:46:06 criu kernel: [   35.434505] CR2: 0000000000000013 CR3: 0000000129220000 CR4: 00000000000006e0
> Oct  9 20:46:06 criu kernel: [   35.435619] Call Trace:
> Oct  9 20:46:06 criu kernel: [   35.435998]  evict+0xc2/0x190
> Oct  9 20:46:06 criu kernel: [   35.436450]  iput+0x1de/0x230
> Oct  9 20:46:06 criu kernel: [   35.436901]  dentry_unlink_inode+0xbd/0x160
> Oct  9 20:46:06 criu kernel: [   35.437562]  __dentry_kill+0xba/0x160
> Oct  9 20:46:06 criu kernel: [   35.438114]  shrink_dentry_list+0x114/0x2f0
> Oct  9 20:46:06 criu kernel: [   35.438739]  shrink_dcache_parent+0x25/0x80
> Oct  9 20:46:06 criu kernel: [   35.439365]  do_one_tree+0xd/0x50
> Oct  9 20:46:06 criu kernel: [   35.439874]  shrink_dcache_for_umount+0x28/0x80
> Oct  9 20:46:06 criu kernel: [   35.440551]  generic_shutdown_super+0x1a/0x110
> Oct  9 20:46:06 criu kernel: [   35.441252]  kill_litter_super+0x24/0x40
> Oct  9 20:46:06 criu kernel: [   35.441867]  deactivate_locked_super+0x39/0x70
> Oct  9 20:46:06 criu kernel: [   35.442531]  deactivate_super+0x49/0x50
> Oct  9 20:46:06 criu kernel: [   35.443105]  cleanup_mnt+0x3a/0x70
> Oct  9 20:46:06 criu kernel: [   35.443626]  __cleanup_mnt+0xd/0x10
> Oct  9 20:46:06 criu kernel: [   35.444151]  task_work_run+0x9a/0xd0
> Oct  9 20:46:06 criu kernel: [   35.444690]  do_exit+0x313/0xc10
> Oct  9 20:46:06 criu kernel: [   35.445215]  do_group_exit+0x42/0xc0
> Oct  9 20:46:06 criu kernel: [   35.445751]  SyS_exit_group+0xf/0x10
> Oct  9 20:46:06 criu kernel: [   35.446289]  entry_SYSCALL_64_fastpath+0x1a/0xa5
> Oct  9 20:46:06 criu kernel: [   35.446979] RIP: 0033:0x7f69f25ed748
> Oct  9 20:46:06 criu kernel: [   35.447530] RSP: 002b:00007fffc9953b08 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> Oct  9 20:46:06 criu kernel: [   35.448611] RAX: ffffffffffffffda RBX: 00007f69f28e6540 RCX: 00007f69f25ed748
> Oct  9 20:46:06 criu kernel: [   35.449667] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> Oct  9 20:46:06 criu kernel: [   35.450678] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff98
> Oct  9 20:46:06 criu kernel: [   35.451696] R10: 00007fffc9953a58 R11: 0000000000000246 R12: 00007f69f2b03700
> Oct  9 20:46:06 criu kernel: [   35.452745] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> Oct  9 20:46:06 criu kernel: [   35.453761] Code: 2f fd ff 85 c0 75 08 48 c7 43 30 a0 0f 82 81 5b 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 48 8b 9f 38 02 00 00 49 89 fc <f6> 43 13 10 74 0b 48 8b 7b 48 31 f6 e8 9e 58 fa ff 4c 89 e7 e8
> Oct  9 20:46:06 criu kernel: [   35.456484] RIP: bm_evict_inode+0x11/0x40 RSP: ffffc90000abfc58
> Oct  9 20:46:06 criu kernel: [   35.457326] CR2: 0000000000000013
> Oct  9 20:46:06 criu kernel: [   35.457807] ---[ end trace 773951adf548e79e ]---

-- 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: null dereference in binfmt misc
  2017-10-09 21:19 null dereference in binfmt misc Tycho Andersen
  2017-10-10  6:49 ` Santosh Sivaraj
@ 2017-10-10 11:16 ` Oleg Nesterov
  2017-10-10 12:04   ` Oleg Nesterov
  1 sibling, 1 reply; 4+ messages in thread
From: Oleg Nesterov @ 2017-10-10 11:16 UTC (permalink / raw)
  To: Tycho Andersen; +Cc: Kees Cook, linux-kernel

On 10/09, Tycho Andersen wrote:
> Hi,
>
> It looks like eb23aa031 ("exec: binfmt_misc: remove the confusing
> e->interp_file != NULL checks") uncovered a bug for me (see the trace below,
> which I'm afraid isn't very helpful).

Well, I think this commit uncovered the fact I am stupid, although there is
nothing new. I forgot about iput() in bm_register_write's error paths, it can
be called with MISC_FMT_OPEN_FILE && interp_file == NULL.

I'll try to cleanup bm_register_write() to make this impossible, or perhaps
I will just restore the interp_file != NULL check in evict.

Before that, could you please try the debugging patch below? To ensure you
didn't hit another problem.

Thanks!

Oleg.


--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -589,12 +589,18 @@ static struct inode *bm_get_inode(struct super_block *sb, int mode)
 	return inode;
 }
 
+#define XXX (void*)1234
+
 static void bm_evict_inode(struct inode *inode)
 {
 	Node *e = inode->i_private;
 
-	if (e->flags & MISC_FMT_OPEN_FILE)
-		filp_close(e->interp_file, NULL);
+	if (e->flags & MISC_FMT_OPEN_FILE) {
+		if (e->interp_file == XXX)
+			pr_err("register: hit XXX\n");
+		else
+			filp_close(e->interp_file, NULL);
+	}
 
 	clear_inode(inode);
 	kfree(e);
@@ -687,7 +693,6 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
 	int err = 0;
 
 	e = create_entry(buffer, count);
-
 	if (IS_ERR(e))
 		return PTR_ERR(e);
 
@@ -709,6 +714,9 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
 
 	err = simple_pin_fs(&bm_fs_type, &bm_mnt, &entry_count);
 	if (err) {
+		pr_err("register: failed to pin, f=%d", !!(e->flags & MISC_FMT_OPEN_FILE));
+		if (e->flags & MISC_FMT_OPEN_FILE)
+			e->interp_file = XXX;
 		iput(inode);
 		inode = NULL;
 		goto out2;
@@ -720,7 +728,8 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
 		f = open_exec(e->interpreter);
 		if (IS_ERR(f)) {
 			err = PTR_ERR(f);
-			pr_notice("register: failed to install interpreter file %s\n", e->interpreter);
+			pr_err("register: failed to install interpreter\n");
+			e->interp_file = XXX;
 			simple_release_fs(&bm_mnt, &entry_count);
 			iput(inode);
 			inode = NULL;

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: null dereference in binfmt misc
  2017-10-10 11:16 ` Oleg Nesterov
@ 2017-10-10 12:04   ` Oleg Nesterov
  0 siblings, 0 replies; 4+ messages in thread
From: Oleg Nesterov @ 2017-10-10 12:04 UTC (permalink / raw)
  To: Tycho Andersen; +Cc: Kees Cook, linux-kernel

On 10/10, Oleg Nesterov wrote:
>
> On 10/09, Tycho Andersen wrote:
> > Hi,
> >
> > It looks like eb23aa031 ("exec: binfmt_misc: remove the confusing
> > e->interp_file != NULL checks") uncovered a bug for me (see the trace below,
> > which I'm afraid isn't very helpful).
>
> Well, I think this commit uncovered the fact I am stupid, although there is
> nothing new. I forgot about iput() in bm_register_write's error paths, it can
> be called with MISC_FMT_OPEN_FILE && interp_file == NULL.
>
> I'll try to cleanup bm_register_write() to make this impossible, or perhaps
> I will just restore the interp_file != NULL check in evict.

Yes, but...

> Before that, could you please try the debugging patch below? To ensure you
> didn't hit another problem.

please ignore. scripts/decodecode suggests you hit another problem,
inode->i_private is NULL.

I'll send the patch today, thanks.

Oleg.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-10-10 12:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-09 21:19 null dereference in binfmt misc Tycho Andersen
2017-10-10  6:49 ` Santosh Sivaraj
2017-10-10 11:16 ` Oleg Nesterov
2017-10-10 12:04   ` Oleg Nesterov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox