glibc:hjl/pr19679/2.23

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

2fe5d64... by "H.J. Lu" <email address hidden> on 2016-02-19

[x86_64] Set DL_RUNTIME_UNALIGNED_VEC_SIZE to 8

Due to GCC bug:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

__tls_get_addr may be called with 8-byte stack alignment. Although
this bug has been fixed in GCC 4.9.4, 5.3 and 6, we can't assume
that stack will be always aligned at 16 bytes. Since SSE optimized
memory/string functions with aligned SSE register load and store are
used in the dynamic linker, we must set DL_RUNTIME_UNALIGNED_VEC_SIZE
to 8 so that _dl_runtime_resolve_sse will align the stack before
calling _dl_fixup:

Dump of assembler code for function _dl_runtime_resolve_sse:
   0x00007ffff7deea90 <+0>: push %rbx
   0x00007ffff7deea91 <+1>: mov %rsp,%rbx
   0x00007ffff7deea94 <+4>: and $0xfffffffffffffff0,%rsp
                                ^^^^^^^^^^^ Align stack to 16 bytes
   0x00007ffff7deea98 <+8>: sub $0x100,%rsp
   0x00007ffff7deea9f <+15>: mov %rax,0xc0(%rsp)
   0x00007ffff7deeaa7 <+23>: mov %rcx,0xc8(%rsp)
   0x00007ffff7deeaaf <+31>: mov %rdx,0xd0(%rsp)
   0x00007ffff7deeab7 <+39>: mov %rsi,0xd8(%rsp)
   0x00007ffff7deeabf <+47>: mov %rdi,0xe0(%rsp)
   0x00007ffff7deeac7 <+55>: mov %r8,0xe8(%rsp)
   0x00007ffff7deeacf <+63>: mov %r9,0xf0(%rsp)
   0x00007ffff7deead7 <+71>: movaps %xmm0,(%rsp)
   0x00007ffff7deeadb <+75>: movaps %xmm1,0x10(%rsp)
   0x00007ffff7deeae0 <+80>: movaps %xmm2,0x20(%rsp)
   0x00007ffff7deeae5 <+85>: movaps %xmm3,0x30(%rsp)
   0x00007ffff7deeaea <+90>: movaps %xmm4,0x40(%rsp)
   0x00007ffff7deeaef <+95>: movaps %xmm5,0x50(%rsp)
   0x00007ffff7deeaf4 <+100>: movaps %xmm6,0x60(%rsp)
   0x00007ffff7deeaf9 <+105>: movaps %xmm7,0x70(%rsp)

 [BZ #19679]
 * sysdeps/x86_64/dl-trampoline.S (DL_RUNIME_UNALIGNED_VEC_SIZE):
 Renamed to ...
 (DL_RUNTIME_UNALIGNED_VEC_SIZE): This. Set to 8.
 (DL_RUNIME_RESOLVE_REALIGN_STACK): Renamed to ...
 (DL_RUNTIME_RESOLVE_REALIGN_STACK): This. Updated.
 (DL_RUNIME_RESOLVE_REALIGN_STACK): Renamed to ...
 (DL_RUNTIME_RESOLVE_REALIGN_STACK): This.
 * sysdeps/x86_64/dl-trampoline.h
 (DL_RUNIME_RESOLVE_REALIGN_STACK): Renamed to ...
 (DL_RUNTIME_RESOLVE_REALIGN_STACK): This.

e742928... by Adhemerval Zanella <email address hidden> on 2016-02-18

Regenerated configure scripts.

d3a793f... by Adhemerval Zanella on 2016-02-18

Regenerate libc.pot for 2.23.

792c8dd... by Adhemerval Zanella on 2016-02-18

Updated translations for 2.23.

Cherry-pick from 31ef23afe2fc94ff2a3ec61f2e76ca973ae09cbd.

ab30899... by Adhemerval Zanella on 2016-02-18

Update version.h and include/features.h for 2.23 release

ad372e2... by Adhemerval Zanella on 2016-02-18

Update NEWS with fixed bugs for 2.23 release

16396c4... by H.J. Lu on 2016-02-18

Add _STRING_INLINE_unaligned and string_private.h

As discussed in

https://sourceware.org/ml/libc-alpha/2015-10/msg00403.html

the setting of _STRING_ARCH_unaligned currently controls the external
GLIBC ABI as well as selecting the use of unaligned accesses withing
GLIBC.

Since _STRING_ARCH_unaligned was recently changed for AArch64, this
would potentially break the ABI in GLIBC 2.23, so split the uses and add
_STRING_INLINE_unaligned to select the string ABI. This setting must be
fixed for each target, while _STRING_ARCH_unaligned may be changed from
release to release. _STRING_ARCH_unaligned is used unconditionally in
glibc. But <bits/string.h>, which defines _STRING_ARCH_unaligned, isn't
included with -Os. Since _STRING_ARCH_unaligned is internal to glibc and
may change between glibc releases, it should be made private to glibc.
_STRING_ARCH_unaligned should defined in the new string_private.h heade
file which is included unconditionally from internal <string.h> for glibc
build.

 [BZ #19462]
 * bits/string.h (_STRING_ARCH_unaligned): Renamed to ...
 (_STRING_INLINE_unaligned): This.
 * include/string.h: Include <string_private.h>.
 * string/bits/string2.h: Replace _STRING_ARCH_unaligned with
 _STRING_INLINE_unaligned.
 * sysdeps/aarch64/bits/string.h (_STRING_ARCH_unaligned): Removed.
 (_STRING_INLINE_unaligned): New.
 * sysdeps/aarch64/string_private.h: New file.
 * sysdeps/generic/string_private.h: Likewise.
 * sysdeps/m68k/m680x0/m68020/string_private.h: Likewise.
 * sysdeps/s390/string_private.h: Likewise.
 * sysdeps/x86/string_private.h: Likewise.
 * sysdeps/m68k/m680x0/m68020/bits/string.h
 (_STRING_ARCH_unaligned): Renamed to ...
 (_STRING_INLINE_unaligned): This.
 * sysdeps/s390/bits/string.h (_STRING_ARCH_unaligned): Renamed
 to ...
 (_STRING_INLINE_unaligned): This.
 * sysdeps/sparc/bits/string.h (_STRING_ARCH_unaligned): Renamed
 to ...
 (_STRING_INLINE_unaligned): This.
 * sysdeps/x86/bits/string.h (_STRING_ARCH_unaligned): Renamed
 to ...
 (_STRING_INLINE_unaligned): This.

6400ae6... by Florian Weimer on 2016-02-18

NEWS: List additional fixed security bugs

a5df321... by Andrew Senkevich <email address hidden> on 2016-02-17

Use PIC relocation in ALIAS_IMPL

Since libmvec_nonshared.a may be linked into shared objects, ALIAS_IMPL
should use PIC relocation.

 [BZ #19590]
 * sysdeps/x86_64/fpu/svml_finite_alias.S (ALIAS_IMPL): Use PIC
 relocation.

e9db92d... by Carlos O'Donell <email address hidden> on 2016-02-17

CVE-2015-7547: getaddrinfo() stack-based buffer overflow (Bug 18665).

* A stack-based buffer overflow was found in libresolv when invoked from
  libnss_dns, allowing specially crafted DNS responses to seize control
  of execution flow in the DNS client. The buffer overflow occurs in
  the functions send_dg (send datagram) and send_vc (send TCP) for the
  NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC
  family. The use of AF_UNSPEC triggers the low-level resolver code to
  send out two parallel queries for A and AAAA. A mismanagement of the
  buffers used for those queries could result in the response of a query
  writing beyond the alloca allocated buffer created by
  _nss_dns_gethostbyname4_r. Buffer management is simplified to remove
  the overflow. Thanks to the Google Security Team and Red Hat for
  reporting the security impact of this issue, and Robert Holiday of
  Ciena for reporting the related bug 18665. (CVE-2015-7547)

See also:
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html