From patchwork Fri Apr 22 20:47:17 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Dapper, CVE-2010-4249, 1/1] af_unix: limit unix_tot_inflight, CVE-2010-4249 Date: Fri, 22 Apr 2011 10:47:17 -0000 From: Brad Figg X-Patchwork-Id: 92584 Message-Id: <1303505237-12625-1-git-send-email-brad.figg@canonical.com> To: kernel-team@lists.ubuntu.com From: Eric Dumazet 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 Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Brad Figg Acked-by: Tim Gardner --- 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); }