From owner-freebsd-security  Mon Dec 22 09:22:17 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA07545
          for security-outgoing; Mon, 22 Dec 1997 09:22:17 -0800 (PST)
          (envelope-from owner-freebsd-security)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07527
          for <freebsd-security@FreeBSD.ORG>; Mon, 22 Dec 1997 09:22:10 -0800 (PST)
          (envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id EAA32525; Tue, 23 Dec 1997 04:17:59 +1100
Date: Tue, 23 Dec 1997 04:17:59 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199712221717.EAA32525@godzilla.zeta.org.au>
To: cschuber@uumail.gov.bc.ca, toor@dyson.iquest.net
Subject: Re: Is this something to worry about?
Cc: dhawk@river.org, freebsd-security@FreeBSD.ORG, mike@smith.net.au
Sender: owner-freebsd-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>I get this behavior consistently under 2.2.2 when running restore.  If I 
>restore a file I can repeat this 100% of the time.  Another way to repeat this 
>100% of the time is to use GDB and set a breakpoint in a program.
>
>My questions are, is this a VM fix or a PROCFS fix?  Do you feel comfortable 
>enough with the fix to have this merged into -stable by the time that 2.2.6 is 
>released?

The gdb fix is both:

#dyson       97/04/05 18:29:49
#
#  Modified:    sys/i386/i386  trap.c
#               sys/miscfs/procfs  procfs_mem.c
#               sys/vm    vm_fault.c vm_map.c vm_map.h vm_prot.h
#  Log:
#  Fix the gdb executable modify problem.  Thanks to the detective work
#  by Alan Cox <alc@cs.rice.edu>, and his description of the problem.
#  
#  The bug was primarily in procfs_mem, but the mistake likely happened
#  due to the lack of vm system support for the operation.  I added
#  better support for selective marking of page dirty flags so that
#  vm_map_pageable(wiring) will not cause this problem again.
#  
#  The code in procfs_mem is now less bogus (but maybe still a little
#  so.)
#  
#  Revision  Changes    Path
#  1.89      +7 -7      src/sys/i386/i386/trap.c
#  1.24      +47 -80    src/sys/miscfs/procfs/procfs_mem.c
#  1.67      +11 -9     src/sys/vm/vm_fault.c
#  1.73      +11 -3     src/sys/vm/vm_map.c
#  1.25      +7 -4      src/sys/vm/vm_map.h
#  1.8       +2 -1      src/sys/vm/vm_prot.h

There is also at least one fix to the fix.

I don't know anything about the restore problem.  restore doesn't seem to
use procfs.

I'm not comfortable merging anything into -stable, since I never run it.

Bruce