From linux-kernel-owner+willy=40w.ods.org@vger.kernel.org  Thu Apr  8 03:17:06 2004
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: from willy.net1.nerim.net (vax [10.2.1.2])
	by alpha.home.local (8.12.4/8.12.1) with ESMTP id i381H5Df010481
	for <willy@w.ods.org>; Thu, 8 Apr 2004 03:17:05 +0200
Received: from vger.kernel.org (vger.kernel.org [67.72.78.212])
	by willy.net1.nerim.net (8.12.9/8.12.1) with ESMTP id i382IJCc010809
	for <willy@w.ods.org>; Thu, 8 Apr 2004 04:18:22 +0200 (CEST)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261416AbUDHCON (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 7 Apr 2004 22:14:13 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261422AbUDHCON
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 7 Apr 2004 22:14:13 -0400
Received: from zcamail05.zca.compaq.com ([161.114.32.105]:2833 "EHLO
	zcamail05.zca.compaq.com") by vger.kernel.org with ESMTP
	id S261416AbUDHCOL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 7 Apr 2004 22:14:11 -0400
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103])
	by zcamail05.zca.compaq.com (Postfix) with ESMTP
	id 01087B8B4; Wed,  7 Apr 2004 19:14:11 -0700 (PDT)
Received: from kahuna.lax.cpqcorp.net (kahuna.lax.cpqcorp.net [16.61.166.23])
	by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP
	id 632075B63; Wed,  7 Apr 2004 22:14:09 -0400 (EDT)
Received: from jbyrne by kahuna.lax.cpqcorp.net with local (Exim 3.35 #1 (Debian))
	id 1BBP3Q-0007o9-00; Wed, 07 Apr 2004 19:14:08 -0700
To: linux-kernel@vger.kernel.org
From: john.l.byrne@hp.com
Cc: marcelo.tosatti@cyclades.com, akpm@osdl.org
Subject: [PATCH]: 2.4/2.6 do_fork() error path memory leak
Message-Id: <E1BBP3Q-0007o9-00@kahuna.lax.cpqcorp.net>
Date: 	Wed, 07 Apr 2004 19:14:08 -0700
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Status: RO
Content-Length: 1443
Lines: 40


In do_fork(), if an error occurs after the mm_struct for the child has
been allocated, it is never freed. The exit_mm() meant to free it
increments the mm_count and this count is never decremented. (For a
running process that is exitting, schedule() takes care this; however,
the child process being cleaned up is not running.) In the CLONE_VM
case, the parent's mm_struct will get an extra mm_count and so it will
never be freed.

This patch against 2.4.25 should fix both the CLONE_VM and the not
CLONE_VM case; the test of p->active_mm prevents a panic in the case
that a kernel-thread is being cloned.

It looks from the code that the problem exists in 2.6 as well; I can
send a separate patch for that, if necessary.

John Byrne

diff -Nar -U 4 linux-2.4.25/kernel/fork.c linux-2.4.25-new/kernel/fork.c
--- linux-2.4.25/kernel/fork.c	2004-02-18 05:36:32.000000000 -0800
+++ linux-2.4.25-new/kernel/fork.c	2004-04-07 17:43:29.000000000 -0700
@@ -825,8 +825,10 @@
 bad_fork_cleanup_namespace:
 	exit_namespace(p);
 bad_fork_cleanup_mm:
 	exit_mm(p);
+	if (p->active_mm)
+		mmdrop(p->active_mm);
 bad_fork_cleanup_sighand:
 	exit_sighand(p);
 bad_fork_cleanup_fs:
 	exit_fs(p); /* blocking */



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

