Date: Wed, 4 Jun 2014 04:47:10 +0000 (UTC) From: Xin LI <delphij@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r45005 - head/share/security/advisories Message-ID: <201406040447.s544lAre057180@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201406040447.s544lAre057180>