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.
gcc trunk bug. It miscompiles posix/execvpe.c. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433
Multiple off-by-ones have been found, see the gcc bug. Possibly introduced by commit 1eb8930608.
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(-)
Fixed by 6c9e1be87a37bfac0bf6c80a38171383ac3527e6.
Adhemerval, why do you commit your patch when Dominik pointed out that you now write past the array bounds in the else branch?
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(-)
53 char *new_argv[argc + 1]; ... 56 if (argc > 1) ... 58 else 59 new_argv[2] = NULL;
Because I pushed before I noted his last remarks. I will sort this out.
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(-)
It should be fixed by 8047e7cf7152a356510f51c18c5a198865470af2 now.
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(-)