diff mbox series

proc: Handle umounts cleanly

Message ID 878siwioxj.fsf@x220.int.ebiederm.org (mailing list archive)
State New, archived
Headers show
Series proc: Handle umounts cleanly | expand

Commit Message

Eric W. Biederman April 15, 2020, 6:28 p.m. UTC
syzbot writes:
> KASAN: use-after-free Read in dput (2)
>
> proc_fill_super: allocate dentry failed
> ==================================================================
> BUG: KASAN: use-after-free in fast_dput fs/dcache.c:727 [inline]
> BUG: KASAN: use-after-free in dput+0x53e/0xdf0 fs/dcache.c:846
> Read of size 4 at addr ffff88808a618cf0 by task syz-executor.0/8426
>
> CPU: 0 PID: 8426 Comm: syz-executor.0 Not tainted 5.6.0-next-20200412-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x188/0x20d lib/dump_stack.c:118
>  print_address_description.constprop.0.cold+0xd3/0x315 mm/kasan/report.c:382
>  __kasan_report.cold+0x35/0x4d mm/kasan/report.c:511
>  kasan_report+0x33/0x50 mm/kasan/common.c:625
>  fast_dput fs/dcache.c:727 [inline]
>  dput+0x53e/0xdf0 fs/dcache.c:846
>  proc_kill_sb+0x73/0xf0 fs/proc/root.c:195
>  deactivate_locked_super+0x8c/0xf0 fs/super.c:335
>  vfs_get_super+0x258/0x2d0 fs/super.c:1212
>  vfs_get_tree+0x89/0x2f0 fs/super.c:1547
>  do_new_mount fs/namespace.c:2813 [inline]
>  do_mount+0x1306/0x1b30 fs/namespace.c:3138
>  __do_sys_mount fs/namespace.c:3347 [inline]
>  __se_sys_mount fs/namespace.c:3324 [inline]
>  __x64_sys_mount+0x18f/0x230 fs/namespace.c:3324
>  do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
>  entry_SYSCALL_64_after_hwframe+0x49/0xb3
> RIP: 0033:0x45c889
> Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffc1930ec48 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000001324914 RCX: 000000000045c889
> RDX: 0000000020000140 RSI: 0000000020000040 RDI: 0000000000000000
> RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
> R13: 0000000000000749 R14: 00000000004ca15a R15: 0000000000000013

Looking at the code now that it the internal mount of proc is no
longer used it is possible to unmount proc.   If proc is unmounted
the fields of the pid namespace that were used for filesystem
specific state are not reinitialized.

Which means that proc_self and proc_thread_self can be pointers to
already freed dentries.

The reported user after free appears to be from mounting and
unmounting proc followed by mounting proc again and using error
injection to cause the new root dentry allocation to fail.  This in
turn results in proc_kill_sb running with proc_self and
proc_thread_self still retaining their values from the previous mount
of proc.  Then calling dput on either proc_self of proc_thread_self
will result in double put.  Which KASAN sees as a use after free.

Solve this by always reinitializing the filesystem state stored
in the struct pid_namespace, when proc is unmounted.

Reported-by: syzbot+72868dd424eb66c6b95f@syzkaller.appspotmail.com
Fixes: 69879c01a0c3 ("proc: Remove the now unnecessary internal mount of proc")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 fs/proc/root.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Christian Brauner April 15, 2020, 7:36 p.m. UTC | #1
On Wed, Apr 15, 2020 at 01:28:24PM -0500, Eric W. Biederman wrote:
> syzbot writes:
> > KASAN: use-after-free Read in dput (2)
> >
> > proc_fill_super: allocate dentry failed
> > ==================================================================
> > BUG: KASAN: use-after-free in fast_dput fs/dcache.c:727 [inline]
> > BUG: KASAN: use-after-free in dput+0x53e/0xdf0 fs/dcache.c:846
> > Read of size 4 at addr ffff88808a618cf0 by task syz-executor.0/8426
> >
> > CPU: 0 PID: 8426 Comm: syz-executor.0 Not tainted 5.6.0-next-20200412-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:77 [inline]
> >  dump_stack+0x188/0x20d lib/dump_stack.c:118
> >  print_address_description.constprop.0.cold+0xd3/0x315 mm/kasan/report.c:382
> >  __kasan_report.cold+0x35/0x4d mm/kasan/report.c:511
> >  kasan_report+0x33/0x50 mm/kasan/common.c:625
> >  fast_dput fs/dcache.c:727 [inline]
> >  dput+0x53e/0xdf0 fs/dcache.c:846
> >  proc_kill_sb+0x73/0xf0 fs/proc/root.c:195
> >  deactivate_locked_super+0x8c/0xf0 fs/super.c:335
> >  vfs_get_super+0x258/0x2d0 fs/super.c:1212
> >  vfs_get_tree+0x89/0x2f0 fs/super.c:1547
> >  do_new_mount fs/namespace.c:2813 [inline]
> >  do_mount+0x1306/0x1b30 fs/namespace.c:3138
> >  __do_sys_mount fs/namespace.c:3347 [inline]
> >  __se_sys_mount fs/namespace.c:3324 [inline]
> >  __x64_sys_mount+0x18f/0x230 fs/namespace.c:3324
> >  do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> >  entry_SYSCALL_64_after_hwframe+0x49/0xb3
> > RIP: 0033:0x45c889
> > Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007ffc1930ec48 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> > RAX: ffffffffffffffda RBX: 0000000001324914 RCX: 000000000045c889
> > RDX: 0000000020000140 RSI: 0000000020000040 RDI: 0000000000000000
> > RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
> > R13: 0000000000000749 R14: 00000000004ca15a R15: 0000000000000013
> 
> Looking at the code now that it the internal mount of proc is no
> longer used it is possible to unmount proc.   If proc is unmounted
> the fields of the pid namespace that were used for filesystem
> specific state are not reinitialized.
> 
> Which means that proc_self and proc_thread_self can be pointers to
> already freed dentries.
> 
> The reported user after free appears to be from mounting and
> unmounting proc followed by mounting proc again and using error
> injection to cause the new root dentry allocation to fail.  This in
> turn results in proc_kill_sb running with proc_self and
> proc_thread_self still retaining their values from the previous mount
> of proc.  Then calling dput on either proc_self of proc_thread_self
> will result in double put.  Which KASAN sees as a use after free.
> 
> Solve this by always reinitializing the filesystem state stored
> in the struct pid_namespace, when proc is unmounted.
> 
> Reported-by: syzbot+72868dd424eb66c6b95f@syzkaller.appspotmail.com
> Fixes: 69879c01a0c3 ("proc: Remove the now unnecessary internal mount of proc")
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

Was looking at that earlier right before eod briefly here as well.
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>

Thanks!
Christian
Eric W. Biederman April 15, 2020, 8:17 p.m. UTC | #2
Christian Brauner <christian.brauner@ubuntu.com> writes:

> On Wed, Apr 15, 2020 at 01:28:24PM -0500, Eric W. Biederman wrote:
>> syzbot writes:
>> > KASAN: use-after-free Read in dput (2)
>> >
>> > proc_fill_super: allocate dentry failed
>> > ==================================================================
>> > BUG: KASAN: use-after-free in fast_dput fs/dcache.c:727 [inline]
>> > BUG: KASAN: use-after-free in dput+0x53e/0xdf0 fs/dcache.c:846
>> > Read of size 4 at addr ffff88808a618cf0 by task syz-executor.0/8426
>> >
>> > CPU: 0 PID: 8426 Comm: syz-executor.0 Not tainted 5.6.0-next-20200412-syzkaller #0
>> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> > Call Trace:
>> >  __dump_stack lib/dump_stack.c:77 [inline]
>> >  dump_stack+0x188/0x20d lib/dump_stack.c:118
>> >  print_address_description.constprop.0.cold+0xd3/0x315 mm/kasan/report.c:382
>> >  __kasan_report.cold+0x35/0x4d mm/kasan/report.c:511
>> >  kasan_report+0x33/0x50 mm/kasan/common.c:625
>> >  fast_dput fs/dcache.c:727 [inline]
>> >  dput+0x53e/0xdf0 fs/dcache.c:846
>> >  proc_kill_sb+0x73/0xf0 fs/proc/root.c:195
>> >  deactivate_locked_super+0x8c/0xf0 fs/super.c:335
>> >  vfs_get_super+0x258/0x2d0 fs/super.c:1212
>> >  vfs_get_tree+0x89/0x2f0 fs/super.c:1547
>> >  do_new_mount fs/namespace.c:2813 [inline]
>> >  do_mount+0x1306/0x1b30 fs/namespace.c:3138
>> >  __do_sys_mount fs/namespace.c:3347 [inline]
>> >  __se_sys_mount fs/namespace.c:3324 [inline]
>> >  __x64_sys_mount+0x18f/0x230 fs/namespace.c:3324
>> >  do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
>> >  entry_SYSCALL_64_after_hwframe+0x49/0xb3
>> > RIP: 0033:0x45c889
>> > Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>> > RSP: 002b:00007ffc1930ec48 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
>> > RAX: ffffffffffffffda RBX: 0000000001324914 RCX: 000000000045c889
>> > RDX: 0000000020000140 RSI: 0000000020000040 RDI: 0000000000000000
>> > RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
>> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
>> > R13: 0000000000000749 R14: 00000000004ca15a R15: 0000000000000013
>> 
>> Looking at the code now that it the internal mount of proc is no
>> longer used it is possible to unmount proc.   If proc is unmounted
>> the fields of the pid namespace that were used for filesystem
>> specific state are not reinitialized.
>> 
>> Which means that proc_self and proc_thread_self can be pointers to
>> already freed dentries.
>> 
>> The reported user after free appears to be from mounting and
>> unmounting proc followed by mounting proc again and using error
>> injection to cause the new root dentry allocation to fail.  This in
>> turn results in proc_kill_sb running with proc_self and
>> proc_thread_self still retaining their values from the previous mount
>> of proc.  Then calling dput on either proc_self of proc_thread_self
>> will result in double put.  Which KASAN sees as a use after free.
>> 
>> Solve this by always reinitializing the filesystem state stored
>> in the struct pid_namespace, when proc is unmounted.
>> 
>> Reported-by: syzbot+72868dd424eb66c6b95f@syzkaller.appspotmail.com
>> Fixes: 69879c01a0c3 ("proc: Remove the now unnecessary internal mount of proc")
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Was looking at that earlier right before eod briefly here as well.
> Acked-by: Christian Brauner <christian.brauner@ubuntu.com>

The syzbot report or did you see the failure another way?

Eric
Christian Brauner April 15, 2020, 9:20 p.m. UTC | #3
On Wed, Apr 15, 2020 at 03:17:26PM -0500, Eric W. Biederman wrote:
> Christian Brauner <christian.brauner@ubuntu.com> writes:
> 
> > On Wed, Apr 15, 2020 at 01:28:24PM -0500, Eric W. Biederman wrote:
> >> syzbot writes:
> >> > KASAN: use-after-free Read in dput (2)
> >> >
> >> > proc_fill_super: allocate dentry failed
> >> > ==================================================================
> >> > BUG: KASAN: use-after-free in fast_dput fs/dcache.c:727 [inline]
> >> > BUG: KASAN: use-after-free in dput+0x53e/0xdf0 fs/dcache.c:846
> >> > Read of size 4 at addr ffff88808a618cf0 by task syz-executor.0/8426
> >> >
> >> > CPU: 0 PID: 8426 Comm: syz-executor.0 Not tainted 5.6.0-next-20200412-syzkaller #0
> >> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> >> > Call Trace:
> >> >  __dump_stack lib/dump_stack.c:77 [inline]
> >> >  dump_stack+0x188/0x20d lib/dump_stack.c:118
> >> >  print_address_description.constprop.0.cold+0xd3/0x315 mm/kasan/report.c:382
> >> >  __kasan_report.cold+0x35/0x4d mm/kasan/report.c:511
> >> >  kasan_report+0x33/0x50 mm/kasan/common.c:625
> >> >  fast_dput fs/dcache.c:727 [inline]
> >> >  dput+0x53e/0xdf0 fs/dcache.c:846
> >> >  proc_kill_sb+0x73/0xf0 fs/proc/root.c:195
> >> >  deactivate_locked_super+0x8c/0xf0 fs/super.c:335
> >> >  vfs_get_super+0x258/0x2d0 fs/super.c:1212
> >> >  vfs_get_tree+0x89/0x2f0 fs/super.c:1547
> >> >  do_new_mount fs/namespace.c:2813 [inline]
> >> >  do_mount+0x1306/0x1b30 fs/namespace.c:3138
> >> >  __do_sys_mount fs/namespace.c:3347 [inline]
> >> >  __se_sys_mount fs/namespace.c:3324 [inline]
> >> >  __x64_sys_mount+0x18f/0x230 fs/namespace.c:3324
> >> >  do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> >> >  entry_SYSCALL_64_after_hwframe+0x49/0xb3
> >> > RIP: 0033:0x45c889
> >> > Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> >> > RSP: 002b:00007ffc1930ec48 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> >> > RAX: ffffffffffffffda RBX: 0000000001324914 RCX: 000000000045c889
> >> > RDX: 0000000020000140 RSI: 0000000020000040 RDI: 0000000000000000
> >> > RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
> >> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
> >> > R13: 0000000000000749 R14: 00000000004ca15a R15: 0000000000000013
> >> 
> >> Looking at the code now that it the internal mount of proc is no
> >> longer used it is possible to unmount proc.   If proc is unmounted
> >> the fields of the pid namespace that were used for filesystem
> >> specific state are not reinitialized.
> >> 
> >> Which means that proc_self and proc_thread_self can be pointers to
> >> already freed dentries.
> >> 
> >> The reported user after free appears to be from mounting and
> >> unmounting proc followed by mounting proc again and using error
> >> injection to cause the new root dentry allocation to fail.  This in
> >> turn results in proc_kill_sb running with proc_self and
> >> proc_thread_self still retaining their values from the previous mount
> >> of proc.  Then calling dput on either proc_self of proc_thread_self
> >> will result in double put.  Which KASAN sees as a use after free.
> >> 
> >> Solve this by always reinitializing the filesystem state stored
> >> in the struct pid_namespace, when proc is unmounted.
> >> 
> >> Reported-by: syzbot+72868dd424eb66c6b95f@syzkaller.appspotmail.com
> >> Fixes: 69879c01a0c3 ("proc: Remove the now unnecessary internal mount of proc")
> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> >
> > Was looking at that earlier right before eod briefly here as well.
> > Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
> 
> The syzbot report or did you see the failure another way?

Yep, the syzbot report. I haven't seen other issues so far.

Christian
diff mbox series

Patch

diff --git a/fs/proc/root.c b/fs/proc/root.c
index 2633f10446c3..fbf084a7d14c 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -196,6 +196,13 @@  static void proc_kill_sb(struct super_block *sb)
 	if (ns->proc_thread_self)
 		dput(ns->proc_thread_self);
 	kill_anon_super(sb);
+
+	/* Make the pid namespace safe for a new mount of proc */
+	ns->proc_self = NULL;
+	ns->proc_thread_self = NULL;
+	ns->pid_gid = GLOBAL_ROOT_GID;
+	ns->hide_pid = 0;
+
 	put_pid_ns(ns);
 }