svn commit: r45005 - head/share/security/advisories

[Xin LI]

Author: delphij
Date: Wed Jun  4 04:47:10 2014
New Revision: 45005
URL: http://svnweb.freebsd.org/changeset/doc/45005

Log:
  Revise the errata to provide more correct information.
  
  Submitted by:	kib, gjb

Modified:
  head/share/security/advisories/FreeBSD-EN-14:06.exec.asc

Modified: head/share/security/advisories/FreeBSD-EN-14:06.exec.asc
==============================================================================
--- head/share/security/advisories/FreeBSD-EN-14:06.exec.asc	Wed Jun  4 01:31:23 2014	(r45004)
+++ head/share/security/advisories/FreeBSD-EN-14:06.exec.asc	Wed Jun  4 04:47:10 2014	(r45005)
@@ -26,31 +26,41 @@ Advisories, including descriptions of th
 branches, and the following sections, please visit
 <URL:http://security.freebsd.org/>.
 
+0.   Revision History
+
+v1.0  2014-06-03 Initial release.
+v1.1  2014-06-03 Corrected some technical details for the advisory.
+
 I.   Background
 
-The execve and fexecve system calls transforms the calling process into a
-new process, constructed from an ordinarty file.
+The execve(2) and fexecve(2) system calls transforms the calling process
+into a new process, constructed from an ordinary file.
 
 When executing a new process, the FreeBSD virtual memory subsystem tries to
 optimize the process by avoiding destroying the old virtual memory address
-space when the calling process do not share its address space with another
-process (for instance, via rfork(2) with RFMEM) and when the new min/max
-address limit stays the same.  In the optimized scenario, the virtual memory
-subsystem only removes usermode mappings from the existing virtual memory
-address space instead of destroying and recreating it.
+space when the calling process does not share its address space with another
+process (for instance, via rfork(2) with RFMEM) and when the new
+minimum/maxaximum address limit stays the same.  In the optimized scenario,
+the virtual memory subsystem only removes usermode mappings from the existing
+virtual memory address space instead of destroying and recreating it.
 
 II.  Problem Description
 
-When the virtual memory address space is recreated for the calling process,
-the old virtual memory address space as well as its associated mappings are
-destroyed before thread_single(9) boundary, where threads were allowed to
-run to safely terminate.  If such threads were on other CPUs, the old page
-table pointer may still be referenced.
+When the virtual memory address space is recreated for the calling
+process, the old virtual memory address space, as well as its
+associated mappings, may be destroyed if the old address space is not
+suitable for the new image execution.  The destruction happens before
+other threads in the current process are terminated.  If the address
+space is destroyed, such threads still reference old address space and
+corresponding mapping structures, and an attempt to switch to them to
+gracefully terminate the remaining threads cause a triple fault and
+machine reset.
 
 III. Impact
 
-The system will crash when this happens due to a triple-fault triggered by
-dereferencing an invalid page table pointer.
+The system will reboot without any log or panic message when this
+happens due to a triple-fault triggered by dereferencing an invalid
+page table pointer.
 
 IV.  Workaround
 
@@ -147,17 +157,17 @@ http://security.FreeBSD.org/advisories/F
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (FreeBSD)
 
-iQIcBAEBCgAGBQJTjiDaAAoJEO1n7NZdz2rnNcIQANX2RW/Yeuso43ziviT10iH9
-IBd0Ibazfq4HIVANEGfBF9pkL7vQ4VZzzWJBZEA6r/0qDMVO0mMoFA2/SDAB3oCO
-Wjc2TF/FLNPlrYamO1Comb1lKG8nmXj3C+AEEOyzlxDBLIH4cEuCX6yBbjZgjeuz
-eYTmFWqiMBwjOctZSFzmaZjaG0EtUIig8ELkPePXBP+zGZiBlBRpLuXWTUuRTT1T
-I8YbhEhlvw7rZmtK7rq5uRFfFclmFCC1cYRxKb9o+9tXUL9Qq6q0740hAG/I1HJU
-s7M3gvQZNhFa6B8fC2XbBwe1g51pfcxRkU8ZZ0kIU4064r9CP9In9InmcFKrfZTo
-xNYNiV9/8rY2lHts6cXZgfrJQLfEWzYghlKVBBZpd8syVjt8ozA08YAD4RAzGAsb
-s1cwI9ZCpc9ak6kd9xvDV/ZUmJLE3XS8HkogUd/RBYiu0GTn6MsCIc/pnOpAL1Cq
-BWLmWS8vDT4rcuC828L2VmdfLjrdWcr9DHreiW7xxCX4O+/ktOT43PrgQtjd/mf+
-i0k9OAJRwdoh92ylLkEJqm3kugoDGxOITKHvo2dx+g2ySukIzTv0BCNT9EAJ0kX+
-i4G0eyGNTsIycZcokil1rUzk2giNLa5yqKOZNzPZ3EA7U/knuXDN1rdN0OzrqncY
-WZlllko53SvpSDli15vp
-=A9nK
+iQIcBAEBCgAGBQJTjqLMAAoJEO1n7NZdz2rnlZAQAIyw74OAXftuLAZC6HXHQt5s
+cu9wUFa5+2OUJiVjyh0nGsHH6bu0hXqJ+5lODqGb/5H17vXeazIC/1b1qa4aYyV/
+yJ2JqSFvDAgecs8xpP3jzvhB11bnu7IYTIisJ4kguO2uszH4SC3aWnn5706A6B/v
+fh+o0L+y8O3eAxGCslpUWUC/0m4gco4BzYiziqk1yDCv58UN1Pb9v/OuxE2FKkRe
+aeGTUeXzVUc922TkefXOR4Z6h7I3jL5m4XDO2PfEnpzUanCLPccUHxWy1fBFMN0B
+Pk/i2hcXCSuNXAMPmSjOatLpj40t7ZzSKJvbmmxjTUeOGFomLvkCq6alSjzHbpDT
+3H2vGYspR8rQz5s3VuXNoaAP3mUgeW2tWmk1O6Pz36/tuUB3XqAifAP6PsBkIJrh
+Mw1dlxfeKf9U+FBvwJmarTLMv9cFHmc5bWglrfoom2doWYINAytcBZG5yrYa7nXf
+dhIs1iqF+jyz68XoVSB80UsZet4mtvKgvNDeK0PNgz+IW1/izbya5GqkO29izbiw
+LNU8xhc/tqHENTZeQxwacyfO9gSlqT0/mFGi0ciRqyIpV5e+rkNG0q/jKSDz1Im+
+957zDTZT6tkxGU8SPP/IRgoj48pMFF9kOslikW+4sYSY7zyrx2GP8qXMtSOcmNOB
+WqT612K4k2YB7L/y694b
+=sHOn
 -----END PGP SIGNATURE-----