os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Revise the errata to provide more correct information.

Browse source 
Submitted by:	kib, gjb
This commit is contained in:
Xin LI 2014-06-04 04:47:10 +00:00
parent 62f6c11463
commit dec0f7974c
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=45005
1 changed files with 37 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

64
share/security/advisories/FreeBSD-EN-14:06.exec.asc
View file

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