[Dapper] [CVE-2010-4249] [PATCH 1/1] af_unix: limit unix_tot_inflight, CVE-2010-4249
Brad Figg
brad.figg at canonical.com
Fri Apr 22 20:47:17 UTC 2011
From: Eric Dumazet <eric.dumazet at gmail.com>
CVE-2010-4249
BugLink: http://bugs.launchpad.net/bugs/769182
Vegard Nossum found a unix socket OOM was possible, posting an exploit
program.
My analysis is we can eat all LOWMEM memory before unix_gc() being
called from unix_release_sock(). Moreover, the thread blocked in
unix_gc() can consume huge amount of time to perform cleanup because of
huge working set.
One way to handle this is to have a sensible limit on unix_tot_inflight,
tested from wait_for_unix_gc() and to force a call to unix_gc() if this
limit is hit.
This solves the OOM and also reduce overall latencies, and should not
slowdown normal workloads.
Reported-by: Vegard Nossum <vegard.nossum at gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet at gmail.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Brad Figg <brad.figg at canonical.com>
---
net/unix/garbage.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index 040f952..26d22aa 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -168,9 +168,16 @@ static void maybe_unmark_and_push(struct sock *x)
static int gc_in_progress = 0;
+#define UNIX_INFLIGHT_TRIGGER_GC 16000
void wait_for_unix_gc(void)
{
+ /*
+ * If number of inflight sockets is insane,
+ * force a garbage collect right now.
+ */
+ if (atomic_read(&unix_tot_inflight) > UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress)
+ unix_gc();
wait_event(unix_gc_wait, gc_in_progress == 0);
}
--
1.7.0.4
More information about the kernel-team
mailing list