UNIX sockets kernel panic

UNIX sockets kernel panic

[Andrea Bittau]

The following code causes a kernel panic on Linux 2.6.26:
http://darkircop.org/unix.c

I haven't investigated the bug so I'm not sure what is causing it, and
don't know if it's exploitable.  The code passes unix sockets from one
process to another using unix sockets.  The bug probably has to do with
closing file descriptors.

[I'm not subscribed to the list so please CC me if you answer.]

Re: UNIX sockets kernel panic

[Alexey Dobriyan]

On Thu, Nov 06, 2008 at 12:14:46AM +0000, Andrea Bittau wrote:
> The following code causes a kernel panic on Linux 2.6.26:
> http://darkircop.org/unix.c
> 
> I haven't investigated the bug so I'm not sure what is causing it, and
> don't know if it's exploitable.  The code passes unix sockets from one
> process to another using unix sockets.  The bug probably has to do with
> closing file descriptors.

Aie, nice localhost DoS (random oopses)

BUG: unable to handle kernel paging request at ffff880827feb448
IP: [<ffffffff8022191a>] cfs_rq_of+0x19/0x27
PGD 202063 PUD 0 
Oops: 0000 [#1] SMP 
last sysfs file: /sys/kernel/uevent_seqnum
CPU 0 
Pid: 20940, comm: unix Not tainted 2.6.28-rc3 #2
RIP: 0010:[<ffffffff8022191a>]  [<ffffffff8022191a>] cfs_rq_of+0x19/0x27
RSP: 0018:ffff88017dbd3d08  EFLAGS: 00010046
RAX: ffffffff80505940 RBX: ffff88017f94ad90 RCX: 00000000ffff8801
RDX: ffff880028027440 RSI: ffff88002802f9d8 RDI: ffff88017f94adc8
RBP: ffff88017dbd3d08 R08: ffff88002802f9d8 R09: ffff88002802f9b0
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88002802f940
R13: 0000000000000001 R14: ffff88017dbd3d88 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffffffff804b2540(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff880827feb448 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process unix (pid: 20940, threadinfo ffff88017dbd2000, task ffff88017f94ad90)
Stack:
 ffff88017dbd3d28 ffffffff80224b4b ffff88017f87d5d0 ffff88002802f940
 ffff88017dbd3d48 ffffffff80221ada 0000000000000000 ffff88002802f940
 ffff88017dbd3d68 ffffffff80221b69 ffff88017dbd3d88 ffff88017f87d5d0
Call Trace:
 [<ffffffff80224b4b>] hrtick_update+0x24/0x3f
 [<ffffffff80221ada>] enqueue_task+0x13/0x1e
 [<ffffffff80221b69>] activate_task+0x22/0x2a
 [<ffffffff80224f4b>] try_to_wake_up+0xf9/0x162
 [<ffffffff80233816>] signal_wake_up+0x2b/0x3e
 [<ffffffff80233ada>] ? send_signal+0x166/0x182
 [<ffffffff80235392>] ? do_notify_parent+0x16c/0x19b
 [<ffffffff8027baa2>] ? mntput_no_expire+0x20/0x103
 [<ffffffff80222719>] ? need_resched+0x1e/0x28
 [<ffffffff8027baa2>] ? mntput_no_expire+0x20/0x103
 [<ffffffff8022d5af>] ? do_exit+0x491/0x6cb
 [<ffffffff8022d878>] ? sys_exit_group+0x0/0xe
 [<ffffffff8020b305>] ? tracesys+0xd0/0xd5
Code: 0d 0e 29 00 48 8b 14 ca 48 03 42 08 c9 48 83 c0 70 c3 48 8b 57 d0 55 48 c7 c0 40 59 50 80 48 89 e5 8b 4a 1c 48 8b 15 e6 0d 29 00 <48> 8b 14 ca 48 03 42 08 c9 48 83 c0 70 c3 48 8b 47 50 48 8b 4f 
RIP  [<ffffffff8022191a>] cfs_rq_of+0x19/0x27
 RSP <ffff88017dbd3d08>
CR2: ffff880827feb448
Kernel panic - not syncing: Fatal exception in interrupt

Re: UNIX sockets kernel panic

[David Miller]

From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Thu, 6 Nov 2008 04:13:19 +0300

> On Thu, Nov 06, 2008 at 12:14:46AM +0000, Andrea Bittau wrote:
> > The following code causes a kernel panic on Linux 2.6.26:
> > http://darkircop.org/unix.c
> > 
> > I haven't investigated the bug so I'm not sure what is causing it, and
> > don't know if it's exploitable.  The code passes unix sockets from one
> > process to another using unix sockets.  The bug probably has to do with
> > closing file descriptors.
> 
> Aie, nice localhost DoS (random oopses)

Indeed.  I'm looking at it too and in my case I get random memory
corruption, usually it's skb->destruct being set to garbage and then
we hit the WARN_ON(in_irq()) in net/core/skbuff.c

I think the key is passing a unix socket fd (as opposed to some other
kind of fd) using SCM_RIGHTS and the ordering of the fd closes.

Re: UNIX sockets kernel panic

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Wed, 05 Nov 2008 17:18:22 -0800 (PST)

> From: Alexey Dobriyan <adobriyan@gmail.com>
> Date: Thu, 6 Nov 2008 04:13:19 +0300
> 
> > On Thu, Nov 06, 2008 at 12:14:46AM +0000, Andrea Bittau wrote:
> > > The following code causes a kernel panic on Linux 2.6.26:
> > > http://darkircop.org/unix.c
> > > 
> > > I haven't investigated the bug so I'm not sure what is causing it, and
> > > don't know if it's exploitable.  The code passes unix sockets from one
> > > process to another using unix sockets.  The bug probably has to do with
> > > closing file descriptors.
> > 
> > Aie, nice localhost DoS (random oopses)
> 
> Indeed.  I'm looking at it too and in my case I get random memory
> corruption, usually it's skb->destruct being set to garbage and then
> we hit the WARN_ON(in_irq()) in net/core/skbuff.c
> 
> I think the key is passing a unix socket fd (as opposed to some other
> kind of fd) using SCM_RIGHTS and the ordering of the fd closes.

Andrea, can you try this patch?

net: Fix recursive descent in __scm_destroy().

__scm_destroy() walks the list of file descriptors in the scm_fp_list
pointed to by the scm_cookie argument.

Those, in turn, can close sockets and invoke __scm_destroy() again.

There is nothing which limits how deeply this can occur.

The idea for how to fix this is from Linus.  Basically, we do all of
the fput()s at the top level by collecting all of the scm_fp_list
objects hit by an fput().  Inside of the initial __scm_destroy() we
keep running the list until it is empty.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/include/linux/sched.h b/include/linux/sched.h
index b483f39..295b7c7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1349,6 +1349,8 @@ struct task_struct {
 	 */
 	unsigned long timer_slack_ns;
 	unsigned long default_timer_slack_ns;
+
+	struct list_head	*scm_work_list;
 };
 
 /*
diff --git a/include/net/scm.h b/include/net/scm.h
index 06df126..33e9986 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -14,8 +14,9 @@
 
 struct scm_fp_list
 {
-	int		count;
-	struct file	*fp[SCM_MAX_FD];
+	struct list_head	list;
+	int			count;
+	struct file		*fp[SCM_MAX_FD];
 };
 
 struct scm_cookie
diff --git a/net/core/scm.c b/net/core/scm.c
index 10f5c65..ab242cc 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -75,6 +75,7 @@ static int scm_fp_copy(struct cmsghdr *cmsg, struct scm_fp_list **fplp)
 		if (!fpl)
 			return -ENOMEM;
 		*fplp = fpl;
+		INIT_LIST_HEAD(&fpl->list);
 		fpl->count = 0;
 	}
 	fpp = &fpl->fp[fpl->count];
@@ -106,9 +107,25 @@ void __scm_destroy(struct scm_cookie *scm)
 
 	if (fpl) {
 		scm->fp = NULL;
-		for (i=fpl->count-1; i>=0; i--)
-			fput(fpl->fp[i]);
-		kfree(fpl);
+		if (current->scm_work_list) {
+			list_add_tail(&fpl->list, current->scm_work_list);
+		} else {
+			LIST_HEAD(work_list);
+
+			current->scm_work_list = &work_list;
+
+			list_add(&fpl->list, &work_list);
+			while (!list_empty(&work_list)) {
+				fpl = list_first_entry(&work_list, struct scm_fp_list, list);
+
+				list_del(&fpl->list);
+				for (i=fpl->count-1; i>=0; i--)
+					fput(fpl->fp[i]);
+				kfree(fpl);
+			}
+
+			current->scm_work_list = NULL;
+		}
 	}
 }
 
@@ -284,6 +301,7 @@ struct scm_fp_list *scm_fp_dup(struct scm_fp_list *fpl)
 
 	new_fpl = kmalloc(sizeof(*fpl), GFP_KERNEL);
 	if (new_fpl) {
+		INIT_LIST_HEAD(&new_fpl->list);
 		for (i=fpl->count-1; i>=0; i--)
 			get_file(fpl->fp[i]);
 		memcpy(new_fpl, fpl, sizeof(*fpl));

Re: UNIX sockets kernel panic

[Andrea Bittau]

I'm still seeing problems with your patch.  I'm getting mixed results.
With SMP off, everything seems to work.  With SMP, on my laptop, it
still barfs (.26 and .27).  Here's a screenshot (literally) of .26:
http://darkircop.org/unix.jpg

I can't seem to reproduce it on qemu using -smp.  However, on qemu, with
kernel 2.6.19, your patch, and -smp 2, I can get this one to hang:
http://darkircop.org/unix2.c

On my laptop, with 2.6.19 and SMP on, I think that everything works.
It's likely that it's a scheduling / configuration problem, so I
don't think there's anything magic in .19.