Bug 20847 - tst-vfork3 failure
Summary: tst-vfork3 failure
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: 2.25
Assignee: Adhemerval Zanella
URL: https://gcc.gnu.org/bugzilla/show_bug...
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-20 10:33 UTC by Markus Trippelsdorf
Modified: 2016-12-08 19:27 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2016-11-21 00:00:00
fweimer: security+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Trippelsdorf 2016-11-20 10:33:53 UTC
glibc trunk, linux latest git:

markus@x4 posix % ./tst-vfork3
script 1
script 1
script 1
script 1
script 1
/bin/sh: : No such file or directory
script2.sh failed with status 32512

strace shows:

...
12906 vfork( <unfinished ...>                                                                                                                                                      
12912 execve("/tmp/tst-vfork3.Ox2RZ9/script2.sh", ["script2.sh", "2"], [/* 53 vars */]) = -1 ENOEXEC (Exec format error)                                                           
12912 execve("/bin/sh", ["/bin/sh", "\1", "2"], [/* 53 vars */] <unfinished ...>                                                                                                   
12906 <... vfork resumed> )             = 12912                                                                                                                                    
12906 wait4(12912,  <unfinished ...>                                                                                                                                               
12912 <... execve resumed> )            = 0                                                                                                                                        
12912 brk(NULL)                         = 0x1a60000 
...
12912 open("\1", O_RDONLY)              = -1 ENOENT (No such file or directory)                                                                                                    
12912 stat(".", {st_mode=S_IFDIR|0755, st_size=6840, ...}) = 0                                                                                                                     
12912 stat("/tmp/tst-vfork3.Ox2RZ9/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                                    
12912 stat("/var/texlive_2016/bin/x86_64-linux/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                        
12912 stat("/home/markus/bin/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                                          
12912 stat("/usr/local/bin/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                                            
12912 stat("/usr/bin/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                                                  
12912 stat("/bin/\1", 0x7ffebae61900)   = -1 ENOENT (No such file or directory)                                                                                                    
12912 stat("/opt/bin/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                                                  
12912 stat("/usr/x86_64-pc-linux-gnu/gcc-bin/7.0.0/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                    
12912 stat("/usr/lib64/subversion/bin/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                                 
12912 stat("/usr/games/bin/\1", 0x7ffebae61900) = -1 ENOENT (No such file or directory)                                                                                            
...                                                                                                         
12912 write(2, "/bin/sh: \1: No such file or dire"..., 38) = 3
...

Notice the strange "\1" in the execve() call.
Comment 1 Markus Trippelsdorf 2016-11-20 11:39:04 UTC
gcc trunk bug. It miscompiles posix/execvpe.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433
Comment 2 Andreas Schwab 2016-11-21 11:00:19 UTC
Multiple off-by-ones have been found, see the gcc bug.  Possibly introduced by commit 1eb8930608.
Comment 3 cvs-commit@gcc.gnu.org 2016-11-22 12:25:09 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  6c9e1be87a37bfac0bf6c80a38171383ac3527e6 (commit)
      from  5ee1a4443a3eb0868cef1fe506ae6fb6af33d4ad (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6c9e1be87a37bfac0bf6c80a38171383ac3527e6

commit 6c9e1be87a37bfac0bf6c80a38171383ac3527e6
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Mon Nov 21 11:06:15 2016 -0200

    Fix writes past the allocated array bounds in execvpe (BZ#20847)
    
    This patch fixes an invalid write out or stack allocated buffer in
    2 places at execvpe implementation:
    
      1. On 'maybe_script_execute' function where it allocates the new
         argument list and it does not account that a minimum of argc
         plus 3 elements (default shell path, script name, arguments,
         and ending null pointer) should be considered.  The straightforward
         fix is just to take account of the correct list size on argument
         copy.
    
      2. On '__execvpe' where the executable file name lenght may not
         account for ending '\0' and thus subsequent path creation may
         write past array bounds because it requires to add the terminating
         null.  The fix is to change how to calculate the executable name
         size to add the final '\0' and adjust the rest of the code
         accordingly.
    
    As described in GCC bug report 78433 [1], these issues were masked off by
    GCC because it allocated several bytes more than necessary so that many
    off-by-one bugs went unnoticed.
    
    Checked on x86_64 with a latest GCC (7.0.0 20161121) with -O3 on CFLAGS.
    
    	[BZ #20847]
    	* posix/execvpe.c (maybe_script_execute): Remove write past allocated
    	array bounds.
    	(__execvpe): Likewise.
    
    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog       |    7 +++++++
 posix/execvpe.c |   15 ++++++++++-----
 2 files changed, 17 insertions(+), 5 deletions(-)
Comment 4 Adhemerval Zanella 2016-11-22 12:26:09 UTC
Fixed by 6c9e1be87a37bfac0bf6c80a38171383ac3527e6.
Comment 5 Markus Trippelsdorf 2016-11-22 12:43:40 UTC
Adhemerval, why do you commit your patch when Dominik pointed out
that you now write past the array bounds in the else branch?
Comment 6 cvs-commit@gcc.gnu.org 2016-11-22 12:57:40 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.24/master has been updated
       via  d174436712e3cabce70d6cd771f177b6fe0e097b (commit)
      from  2bdb3d2ee19a6ac61da0a398b10db380e9c92959 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d174436712e3cabce70d6cd771f177b6fe0e097b

commit d174436712e3cabce70d6cd771f177b6fe0e097b
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Mon Nov 21 11:06:15 2016 -0200

    Fix writes past the allocated array bounds in execvpe (BZ#20847)
    
    This patch fixes an invalid write out or stack allocated buffer in
    2 places at execvpe implementation:
    
      1. On 'maybe_script_execute' function where it allocates the new
         argument list and it does not account that a minimum of argc
         plus 3 elements (default shell path, script name, arguments,
         and ending null pointer) should be considered.  The straightforward
         fix is just to take account of the correct list size on argument
         copy.
    
      2. On '__execvpe' where the executable file name lenght may not
         account for ending '\0' and thus subsequent path creation may
         write past array bounds because it requires to add the terminating
         null.  The fix is to change how to calculate the executable name
         size to add the final '\0' and adjust the rest of the code
         accordingly.
    
    As described in GCC bug report 78433 [1], these issues were masked off by
    GCC because it allocated several bytes more than necessary so that many
    off-by-one bugs went unnoticed.
    
    Checked on x86_64 with a latest GCC (7.0.0 20161121) with -O3 on CFLAGS.
    
    	[BZ #20847]
    	* posix/execvpe.c (maybe_script_execute): Remove write past allocated
    	array bounds.
    	(__execvpe): Likewise.
    
    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog       |    7 +++++++
 posix/execvpe.c |   15 ++++++++++-----
 2 files changed, 17 insertions(+), 5 deletions(-)
Comment 7 Markus Trippelsdorf 2016-11-22 13:00:01 UTC
 53   char *new_argv[argc + 1];                                                                                                                                                    
...
 56   if (argc > 1)
...                                                                                                  
 58   else                                                                                                                                                                         
 59     new_argv[2] = NULL;
Comment 8 Adhemerval Zanella 2016-11-22 13:03:35 UTC
Because I pushed before I noted his last remarks.  I will sort this out.
Comment 9 cvs-commit@gcc.gnu.org 2016-12-07 12:06:56 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  8047e7cf7152a356510f51c18c5a198865470af2 (commit)
      from  657c084cd6f69d6cc880c2ae65129a0723d053c5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8047e7cf7152a356510f51c18c5a198865470af2

commit 8047e7cf7152a356510f51c18c5a198865470af2
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Tue Nov 22 16:23:28 2016 -0200

    Fix writes past the allocated array bounds in execvpe (BZ#20847)
    
    Commit 6c9e1be87a37bf wrongly fixes BZ#20847 by lefting the else branch
    on maybe_script_execute to still being able to invalid write on stack
    allocated buffer.  It happens if execvp{e} is executed with an empty
    arguments list ({ NULL }) and although manual states first argument
    should be the script name itself, by convention, old and current
    implementation allows it.
    
    This patch fixes the issue by just account for arguments and not the
    final 'NULL' (since the 'argv + 1' will indeed ignored the script name).
    The empty argument list is handled in a special case with a minimum
    allocated size.  The patch also adds extra tests for such case in
    tst-vfork3.
    
    Tested on x86_64.
    
    	[BZ #20847]
    	* posix/execvpe.c (maybe_script_execute): Remove write past allocated
    	array bounds for else branch.
    	(__execvpe): Style fixes.
    	* posix/tst-vfork3.c (run_script): New function.
    	(create_script): Likewise.
    	(do_test): Use run_script internal function.
    	(do_prepare): Use create_script internal function.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog          |   12 ++++
 posix/execvpe.c    |   19 ++++--
 posix/tst-vfork3.c |  188 +++++++++++++++++++--------------------------------
 3 files changed, 94 insertions(+), 125 deletions(-)
Comment 10 Adhemerval Zanella 2016-12-07 12:08:09 UTC
It should be fixed by 8047e7cf7152a356510f51c18c5a198865470af2 now.
Comment 11 cvs-commit@gcc.gnu.org 2016-12-08 19:27:44 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, gentoo/2.24 has been updated
       via  b73ec923c79ab493a9265930a45800391329571a (commit)
       via  04c5f782796052de9d06975061eb3376ccbcbdb1 (commit)
       via  9b34c1494d8e61bb3d718e2ea83b856030476737 (commit)
       via  2afb8a945ddc104c5ef9aa61f32427c19b681232 (commit)
       via  df13b9c22a0fb690a0ab9dd4af163ae3c459d975 (commit)
       via  b4391b0c7def246a4503db1af683122681c12a56 (commit)
       via  0d5f4a32a34f048b35360a110a0e6d1c87e3eced (commit)
       via  0ab02a62e42e63b058e7a4e160dbe51762ef2c46 (commit)
       via  901db98f36690e4743feefd985c6ba2d7fd19813 (commit)
      from  caafe2b2612be88046d7bad4da42dbc2b07fbcd7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b73ec923c79ab493a9265930a45800391329571a

commit b73ec923c79ab493a9265930a45800391329571a
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Tue Aug 2 09:18:59 2016 +0200

    alpha: fix trunc for big input values
    
    The alpha specific version of trunc and truncf always add and subtract
    0x1.0p23 or 0x1.0p52 even for big values. This causes this kind of
    errors in the testsuite:
    
      Failure: Test: trunc_towardzero (0x1p107)
      Result:
       is:          1.6225927682921334e+32   0x1.fffffffffffffp+106
       should be:   1.6225927682921336e+32   0x1.0000000000000p+107
       difference:  1.8014398509481984e+16   0x1.0000000000000p+54
       ulp       :  0.5000
       max.ulp   :  0.0000
    
    Change this by returning the input value when its absolute value is
    greater than 0x1.0p23 or 0x1.0p52. NaN have to go through the add and
    subtract operations to get possibly silenced.
    
    Finally remove the code to handle inexact exception, trunc should never
    generate such an exception.
    
    Changelog:
    	* sysdeps/alpha/fpu/s_trunc.c (__trunc): Return the input value
    	when its absolute value is greater than 0x1.0p52.
    	[_IEEE_FP_INEXACT] Remove.
    	* sysdeps/alpha/fpu/s_truncf.c (__truncf): Return the input value
    	when its absolute value is greater than 0x1.0p23.
    	[_IEEE_FP_INEXACT] Remove.
    
    (cherry picked from commit b74d259fe793499134eb743222cd8dd7c74a31ce)
    (cherry picked from commit e6eab16cc302e6c42f79e1af02ce98ebb9a783bc)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=04c5f782796052de9d06975061eb3376ccbcbdb1

commit 04c5f782796052de9d06975061eb3376ccbcbdb1
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Tue Aug 2 09:18:59 2016 +0200

    alpha: fix rint on sNaN input
    
    The alpha version of rint wrongly return sNaN for sNaN input. Fix that
    by checking for NaN and by returning the input value added with itself
    in that case.
    
    Changelog:
    	* sysdeps/alpha/fpu/s_rint.c (__rint): Add argument with itself
    	when it is a NaN.
    	* sysdeps/alpha/fpu/s_rintf.c (__rintf): Likewise.
    
    (cherry picked from commit cb7f9d63b921ea1a1cbb4ab377a8484fd5da9a2b)
    (cherry picked from commit 8eb9a92e0522f2d4f2d4167df919d066c85d3408)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9b34c1494d8e61bb3d718e2ea83b856030476737

commit 9b34c1494d8e61bb3d718e2ea83b856030476737
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Tue Aug 2 09:18:59 2016 +0200

    alpha: fix floor on sNaN input
    
    The alpha version of floor wrongly return sNaN for sNaN input. Fix that
    by checking for NaN and by returning the input value added with itself
    in that case.
    
    Finally remove the code to handle inexact exception, floor should never
    generate such an exception.
    
    Changelog:
    	* sysdeps/alpha/fpu/s_floor.c (__floor): Add argument with itself
    	when it is a NaN.
    	[_IEEE_FP_INEXACT] Remove.
    	* sysdeps/alpha/fpu/s_floorf.c (__floorf): Likewise.
    
    (cherry picked from commit 65cc568cf57156e5230db9a061645e54ff028a41)
    (cherry picked from commit 1912cc082df4739c2388c375f8d486afdaa7d49b)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2afb8a945ddc104c5ef9aa61f32427c19b681232

commit 2afb8a945ddc104c5ef9aa61f32427c19b681232
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Tue Aug 2 09:18:59 2016 +0200

    alpha: fix ceil on sNaN input
    
    The alpha version of ceil wrongly return sNaN for sNaN input. Fix that
    by checking for NaN and by returning the input value added with itself
    in that case.
    
    Finally remove the code to handle inexact exception, ceil should never
    generate such an exception.
    
    Changelog:
    	* sysdeps/alpha/fpu/s_ceil.c (__ceil): Add argument with itself
    	when it is a NaN.
    	[_IEEE_FP_INEXACT] Remove.
    	* sysdeps/alpha/fpu/s_ceilf.c (__ceilf): Likewise.
    
    (cherry picked from commit 062e53c195b4a87754632c7d51254867247698b4)
    (cherry picked from commit 3eff6f84311d2679a58a637e3be78b4ced275762)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=df13b9c22a0fb690a0ab9dd4af163ae3c459d975

commit df13b9c22a0fb690a0ab9dd4af163ae3c459d975
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Sep 6 08:50:55 2016 -0700

    X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508]
    
    There is transition penalty when SSE instructions are mixed with 256-bit
    AVX or 512-bit AVX512 load instructions.  Since _dl_runtime_resolve_avx
    and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM
    registers, there is transition penalty when SSE instructions are used
    with lazy binding on AVX and AVX512 processors.
    
    To avoid SSE transition penalty, if only the lower 128 bits of the first
    8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers
    with the zero upper bits.
    
    For AVX and AVX512 processors which support XGETBV with ECX == 1, we can
    use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers
    or the upper 256 bits of ZMM registers are zero.  We can restore only the
    non-zero portion of vector registers with AVX/AVX512 load instructions
    which will zero-extend upper bits of vector registers.
    
    This patch adds _dl_runtime_resolve_sse_vex which saves and restores
    XMM registers with 128-bit AVX store/load instructions.  It is used to
    preserve YMM/ZMM registers when only the lower 128 bits are non-zero.
    _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added
    and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so
    that we store and load only the non-zero portion of vector registers.
    This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and
    _dl_runtime_profile_avx512 when only the lower 128 bits of vector
    registers are used.
    
    _dl_runtime_resolve_avx_slow is added and used for AVX processors which
    don't support XGETBV with ECX == 1.  Since there is no SSE transition
    penalty on AVX512 processors which don't support XGETBV with ECX == 1,
    _dl_runtime_resolve_avx512_slow isn't provided.
    
    	[BZ #20495]
    	[BZ #20508]
    	* sysdeps/x86/cpu-features.c (init_cpu_features): For Intel
    	processors, set Use_dl_runtime_resolve_slow and set
    	Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1.
    	* sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt):
    	New.
    	(bit_arch_Use_dl_runtime_resolve_slow): Likewise.
    	(index_arch_Use_dl_runtime_resolve_opt): Likewise.
    	(index_arch_Use_dl_runtime_resolve_slow): Likewise.
    	* sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use
    	_dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt
    	if Use_dl_runtime_resolve_opt is set.  Use
    	_dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set.
    	* sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>.
    	(_dl_runtime_resolve_opt): New.  Defined for AVX and AVX512.
    	(_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex.
    	* sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow):
    	New.
    	(_dl_runtime_resolve_opt): Likewise.
    	(_dl_runtime_profile): Define only if _dl_runtime_profile is
    	defined.
    
    (cherry picked from commit fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b4391b0c7def246a4503db1af683122681c12a56

commit b4391b0c7def246a4503db1af683122681c12a56
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Sep 6 08:50:55 2016 -0700

    X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508]
    
    There is transition penalty when SSE instructions are mixed with 256-bit
    AVX or 512-bit AVX512 load instructions.  Since _dl_runtime_resolve_avx
    and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM
    registers, there is transition penalty when SSE instructions are used
    with lazy binding on AVX and AVX512 processors.
    
    To avoid SSE transition penalty, if only the lower 128 bits of the first
    8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers
    with the zero upper bits.
    
    For AVX and AVX512 processors which support XGETBV with ECX == 1, we can
    use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers
    or the upper 256 bits of ZMM registers are zero.  We can restore only the
    non-zero portion of vector registers with AVX/AVX512 load instructions
    which will zero-extend upper bits of vector registers.
    
    This patch adds _dl_runtime_resolve_sse_vex which saves and restores
    XMM registers with 128-bit AVX store/load instructions.  It is used to
    preserve YMM/ZMM registers when only the lower 128 bits are non-zero.
    _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added
    and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so
    that we store and load only the non-zero portion of vector registers.
    This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and
    _dl_runtime_profile_avx512 when only the lower 128 bits of vector
    registers are used.
    
    _dl_runtime_resolve_avx_slow is added and used for AVX processors which
    don't support XGETBV with ECX == 1.  Since there is no SSE transition
    penalty on AVX512 processors which don't support XGETBV with ECX == 1,
    _dl_runtime_resolve_avx512_slow isn't provided.
    
    	[BZ #20495]
    	[BZ #20508]
    	* sysdeps/x86/cpu-features.c (init_cpu_features): For Intel
    	processors, set Use_dl_runtime_resolve_slow and set
    	Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1.
    	* sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt):
    	New.
    	(bit_arch_Use_dl_runtime_resolve_slow): Likewise.
    	(index_arch_Use_dl_runtime_resolve_opt): Likewise.
    	(index_arch_Use_dl_runtime_resolve_slow): Likewise.
    	* sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use
    	_dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt
    	if Use_dl_runtime_resolve_opt is set.  Use
    	_dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set.
    	* sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>.
    	(_dl_runtime_resolve_opt): New.  Defined for AVX and AVX512.
    	(_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex.
    	* sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow):
    	New.
    	(_dl_runtime_resolve_opt): Likewise.
    	(_dl_runtime_profile): Define only if _dl_runtime_profile is
    	defined.
    
    (cherry picked from commit fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604)
    (cherry picked from commit 4b8790c81c1a7b870a43810ec95e08a2e501123d)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0d5f4a32a34f048b35360a110a0e6d1c87e3eced

commit 0d5f4a32a34f048b35360a110a0e6d1c87e3eced
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Thu Nov 24 12:10:13 2016 +0100

    x86_64: fix static build of __memcpy_chk for compilers defaulting to PIC/PIE
    
    When glibc is compiled with gcc 6.2 that has been configured with
    to default to PIC/PIE, the static version of __memcpy_chk is not built,
    as the test is done on PIC instead of SHARED. Fix the test to check for
    SHARED, like it is done for similar functions like memmove_chk.
    
    Changelog:
    	* sysdeps/x86_64/memcpy_chk.S (__memcpy_chk): Check for SHARED
    	instead of PIC.
    
    (cherry picked from commit 380ec16d62f459d5a28cfc25b7b20990c45e1cc9)
    (cherry picked from commit 2d16e81babd1d7b66d10cec0bc6d6d86a7e0c95e)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0ab02a62e42e63b058e7a4e160dbe51762ef2c46

commit 0ab02a62e42e63b058e7a4e160dbe51762ef2c46
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Thu Nov 17 19:15:51 2016 +0000

    MIPS: Add `.insn' to ensure a text label is defined as code not data
    
    Avoid a build error with microMIPS compilation and recent versions of
    GAS which complain if a branch targets a label which is marked as data
    rather than microMIPS code:
    
    ../sysdeps/mips/mips32/crti.S: Assembler messages:
    ../sysdeps/mips/mips32/crti.S:72: Error: branch to a symbol in another ISA mode
    make[2]: *** [.../csu/crti.o] Error 1
    
    as commit 9d862524f6ae ("MIPS: Verify the ISA mode and alignment of
    branch and jump targets") closed a hole in branch processing, making
    relocation calculation respect the ISA mode of the symbol referred.
    This allowed diagnosing the situation where an attempt is made to pass
    control from code assembled for one ISA mode to code assembled for a
    different ISA mode and either relaxing the branch to a cross-mode jump
    or if that is not possible, then reporting this as an error rather than
    letting such code build and then fail unpredictably at the run time.
    
    This however requires the correct annotation of branch targets as code,
    because the ISA mode is not relevant for data symbols and is therefore
    not recorded for them.  The `.insn' pseudo-op is used for this purpose
    and has been supported by GAS since:
    
    Wed Feb 12 14:36:29 1997  Ian Lance Taylor  <ian@cygnus.com>
    
    	* config/tc-mips.c (mips_pseudo_table): Add "insn".
    	(s_insn): New static function.
    	* doc/c-mips.texi: Document .insn.
    
    so there has been no reason to avoid it where required.  More recently
    this pseudo-op has been documented, by the microMIPS architecture
    specification[1][2], as required for the correct interpretation of any
    code label which is not followed by an actual instruction in an assembly
    source.
    
    Use it in our crti.S files then, to mark that the trailing label there
    with no instructions following is indeed not a code bug and the branch
    is legitimate.
    
    References:
    
    [1] "MIPS Architecture for Programmers, Volume II-B: The microMIPS32
        Instruction Set", MIPS Technologies, Inc., Document Number: MD00582,
        Revision 5.04, January 15, 2014, Section 7.1 "Assembly-Level
        Compatibility", p. 533
    
    [2] "MIPS Architecture for Programmers, Volume II-B: The microMIPS64
        Instruction Set", MIPS Technologies, Inc., Document Number: MD00594,
        Revision 5.04, January 15, 2014, Section 8.1 "Assembly-Level
        Compatibility", p. 623
    
    2016-11-23  Matthew Fortune  <Matthew.Fortune@imgtec.com>
                Maciej W. Rozycki  <macro@imgtec.com>
    
    	* sysdeps/mips/mips32/crti.S (_init): Add `.insn' pseudo-op at
    	`.Lno_weak_fn' label.
    	* sysdeps/mips/mips64/n32/crti.S (_init): Likewise.
    	* sysdeps/mips/mips64/n64/crti.S (_init): Likewise.
    
    (cherry picked from commit cfaf1949ff1f8336b54c43796d0e2531bc8a40a2)
    (cherry picked from commit 65a2b63756a4d622b938910d582d8b807c471c9a)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=901db98f36690e4743feefd985c6ba2d7fd19813

commit 901db98f36690e4743feefd985c6ba2d7fd19813
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Mon Nov 21 11:06:15 2016 -0200

    Fix writes past the allocated array bounds in execvpe (BZ#20847)
    
    This patch fixes an invalid write out or stack allocated buffer in
    2 places at execvpe implementation:
    
      1. On 'maybe_script_execute' function where it allocates the new
         argument list and it does not account that a minimum of argc
         plus 3 elements (default shell path, script name, arguments,
         and ending null pointer) should be considered.  The straightforward
         fix is just to take account of the correct list size on argument
         copy.
    
      2. On '__execvpe' where the executable file name lenght may not
         account for ending '\0' and thus subsequent path creation may
         write past array bounds because it requires to add the terminating
         null.  The fix is to change how to calculate the executable name
         size to add the final '\0' and adjust the rest of the code
         accordingly.
    
    As described in GCC bug report 78433 [1], these issues were masked off by
    GCC because it allocated several bytes more than necessary so that many
    off-by-one bugs went unnoticed.
    
    Checked on x86_64 with a latest GCC (7.0.0 20161121) with -O3 on CFLAGS.
    
    	[BZ #20847]
    	* posix/execvpe.c (maybe_script_execute): Remove write past allocated
    	array bounds.
    	(__execvpe): Likewise.
    
    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433
    
    (cherry picked from commit d174436712e3cabce70d6cd771f177b6fe0e097b)

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                      |   25 ++++++++++
 posix/execvpe.c                |   15 ++++--
 sysdeps/alpha/fpu/s_ceil.c     |    7 +--
 sysdeps/alpha/fpu/s_ceilf.c    |    7 +--
 sysdeps/alpha/fpu/s_floor.c    |    7 +--
 sysdeps/alpha/fpu/s_floorf.c   |    7 +--
 sysdeps/alpha/fpu/s_rint.c     |    3 +
 sysdeps/alpha/fpu/s_rintf.c    |    3 +
 sysdeps/alpha/fpu/s_trunc.c    |    7 +--
 sysdeps/alpha/fpu/s_truncf.c   |    7 +--
 sysdeps/mips/mips32/crti.S     |    1 +
 sysdeps/mips/mips64/n32/crti.S |    1 +
 sysdeps/mips/mips64/n64/crti.S |    1 +
 sysdeps/x86/cpu-features.c     |   14 +++++
 sysdeps/x86/cpu-features.h     |    6 ++
 sysdeps/x86_64/dl-machine.h    |   24 ++++++++-
 sysdeps/x86_64/dl-trampoline.S |   20 ++++++++
 sysdeps/x86_64/dl-trampoline.h |  104 +++++++++++++++++++++++++++++++++++++++-
 sysdeps/x86_64/memcpy_chk.S    |    2 +-
 19 files changed, 228 insertions(+), 33 deletions(-)