<!-- SBZ_reproduce  -->
...

Date: Thu, 15 Apr 2004 15:05:05 -0700
From: Chris Wright <chrisw@osdl.org>
To: vendor-sec@lst.de
Subject: [vendor-sec] [john.l.byrne@hp.com: [PATCH]: 2.4/2.6 do_fork() error
     path memory leak]

This has been fixed recently in both 2.4 and 2.6 trees.  It's a trivial
DoS without patch.  Just a heads up.

thanks,
-chris

----- Forwarded message from john.l.byrne@hp.com -----

Date:  Wed, 07 Apr 2004 19:14:08 -0700
From: john.l.byrne@hp.com
To: linux-kernel@vger.kernel.org
Cc: marcelo.tosatti@cyclades.com, akpm@osdl.org
Subject: [PATCH]: 2.4/2.6 do_fork() error path memory leak


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 */

Fixes are in CVS.

CAN-2004-0394

Kernels have been submitted and are waiting for check in.

The CAN-2004-0394 is wrong. It rather belongs to panic() issue.

I'm just noting that not all kernels are affected by this bug. 
--------- 
Affected are: 
 
Kernel 2.4.19 and newer and kernels copy_namespace() 
 
IA64 Kernel, if CONFIG_PERFMON was enabled during compilation, 
and you have to bring the Machine OOM first and then you can 
possibly trigger the leak. 
 
All other Kernels are *not* affected which includes 
so SLES7-s390 (2.4.7) and SLES7-s390x (2.4.17) and likely the PPC 2.4.13. 
 
Two reasons for this: 
 
a) there is no copy_namespace(), the code to exploit using clone() 
   is not there. 
b) Even if you bring the machine OOM first and then try, it you 
   can't reach the code postion because there is no chance to 
   enter the code path where the fix is applied because on these 
   kernels, copy_thread always returns 0: 
Details: 
================================================================================ 
 
int copy_thread(int nr, unsigned long clone_flags, unsigned long 
new_stackp, ..) 
{ 
       .... 
       return 0; 
} 
 
        retval = copy_thread(0, clone_flags, stack_start, stack_size, p, regs); 
        if (retval) 
                goto bad_fork_cleanup_mm; 
 
...... function ....... 
 
        return (success code) 
 
NEVER REACHED BEGIN 
 
bad_fork_cleanup_mm: 
       exit_mm(p); 
       (fix would be inserted here) 
 
NEVER REACHED END 
 
bad_fork_cleanup_sighand: 
================================================================================ 
So there is simply no memory leak at this place on 2.4.17 and 2.4.7. 
 
But we can add the fix anyway, it should not hurt that much ;-) 
 
But SLES7/s390* and SLES7 PCC(2.4.13) Clients are safe from this DoS. 
 
-> I've submited the sles7-s390* kernels also - just for the journalists. 
 
BTW: As "remote/network" is in the "Component" field: 
This can only be exploited if you have control over locally running process, 
for me this is a local DoS "only". 

kernels have been approved and announced.

CVE-2004-0394: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:P/I:N/A:N)