The following reply was made to PR kernel/6469; it has been noted by GNATS.

From: Mike Belopuhov <[email protected]>
To: David Imhoff <[email protected]>
Cc: [email protected]
Subject: Re: kernel/6469: Kernel memory leak upon segfault
Date: Fri, 17 Sep 2010 15:19:19 +0200

 On Fri, Sep 17, 2010 at 13:50 +0200, David Imhoff wrote:
 > >Number:         6469
 > >Category:       kernel
 > >Synopsis:       Kernel leaks memory when an userspace program segfaults
 > >Confidential:   yes
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    bugs
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   unknown
 > >Arrival-Date:   Fri Sep 17 12:00:02 GMT 2010
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     
 > >Release:        
 > >Organization:
 > >Environment:
 >      System      : OpenBSD 4.8
 >      Details     : OpenBSD 4.8-current (GENERIC) #312: Tue Aug 31 21:59:22 
 > MDT 2010
 >                       
 > [email protected]:/usr/src/sys/arch/i386/compile/GENERIC
 > 
 >      Architecture: OpenBSD.i386
 >      Machine     : i386
 > >Description:
 >      When a userspace program segfaults the kernel will leak one 4k block
 >      in the 'temp' subsystem. This cause the kernel to become unusable 
 > after
 >      multiple(/alot of) segfaults. This can be triggered by a crashing 
 > daemon
 >      that is automatically restarted or by a malicious user.
 > 
 >      Problem also occurs in OpenBSD 4.7 and on real hardware(Dell R610).
 > >How-To-Repeat:
 >      1- Compile the following program:
 >              int main() {
 >                      *((int *) 0) = 1;
 >              }
 >      2- run 'sysctl kern.malloc.kmemstat.temp'
 >      3- run compiled program 10 times
 >      4- run 'sysctl kern.malloc.kmemstat.temp', and compare 'inuse' 
 > counter
 >         to the value obtained in step 2. This will be 10 higher.
 > >Fix:
 >      Sorry, no known fix.
 > 
 
 apparently we forget to free program headers when writing core files.
 the diff below fixes the problem for me.
 
 darn, i knew about this problem for quite a while, but didn't dare
 to look in the source.  and of course, huge thanks for the M_TEMP
 hint.
 
 Index: exec_elf.c
 ===================================================================
 RCS file: /home/cvs/src/sys/kern/exec_elf.c,v
 retrieving revision 1.76
 diff -u -p -u -p -r1.76 exec_elf.c
 --- exec_elf.c 26 Jul 2010 01:56:27 -0000      1.76
 +++ exec_elf.c 17 Sep 2010 13:12:47 -0000
 @@ -1078,6 +1079,7 @@ ELFNAMEEND(coredump)(struct proc *p, voi
        }
  
  out:
 +      free(psections, M_TEMP);
        return (error);
  #endif
  }

Reply via email to