linux/poky.git/meta/recipes-core/glibc, branch sumo

glibc: fix CVE-2018-11237

2018-09-27T11:17:46+00:00

glibc: fix CVE-2018-11237 (From OE-Core rev: b9b254da08c1db94ac9ded5f67d7e2e82e3b9be7) (From OE-Core rev: 361c40d4bea101875747eac9c8cc46e92ced173f) Signed-off-by: Zheng Ruoqin Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

glibc: Make bits/wordsize.h multilibbed again

2018-08-16T09:00:08+00:00

As reported by ChenQi, leaving bits/wordsize.h out of being multilibbed introduced a problem in building the SDK for arm64: Error: Transaction check error: file /usr/include/bits/wordsize.h conflicts between attempted installs of lib32-libc6-dev-2.27-r0.armv7vet2hf_vfp and libc6-dev-2.27-r0.aarch64 This effectively reverts commit a74c77d6. (From OE-Core rev: 90ad502bf8faa233e25cf297c1eeefcb0367aea3) (From OE-Core rev: 056ae940da49b38890c2960651f0fdb5331a5fac) Signed-off-by: Daniel Díaz Signed-off-by: Richard Purdie

glibc-locale: Fix host-user-contaminated QA errors

2018-08-01T22:00:28+00:00

Fixes ERROR: glibc-locale-2.27-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-hy-am/usr/lib/locale/hy_AM/LC_MEASUREMENT.tmp is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] (From OE-Core rev: 06d831d12fe2a2366480c79f4c018942937b753a) (From OE-Core rev: 06003fba975adb1c6c374eb31067bf356cc81baa) Signed-off-by: Khem Raj Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

glibc: Avoid multilibbing on wordsize.h

2018-07-29T23:02:52+00:00

Once another header #includes , there is a potential recursion going on because the multilib_header_wrapper.h #includes again! This should not happen because an __arm__ (32-bits) or an __aarch64__ (64-bits) environment guarantees that we will be getting the correct definition, but when building against a different target (like BPF), recursion is what happens. This can be seen, for instance, when building eBPF programs from the kernel with `clang -target bpf', such as the ones located in linux/tools/testing/selftests/bpf/. (From OE-Core rev: a74c77d6168101e88c3a3bce7130f4f52cfab95d) (From OE-Core rev: 7fe620ed0f9bb0404a1929d9c1c47f432f9a6b37) Signed-off-by: Daniel Díaz Signed-off-by: Aníbal Limón Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

glibc: fix CVE-2017-18269 and CVE-2018-11236

2018-07-02T10:41:26+00:00

Backport two CVE patches from the upstream https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=summary commit 5460617d1567657621107d895ee2dd83bc1f88f2 commit cd66c0e584c6d692bc8347b5e72723d02b8a8ada (From OE-Core rev: 398ac946745bbfad55deb382aeafec0be3298819) (From OE-Core rev: 39b480b95c7123cd06b171782c610231d274313a) Signed-off-by: Zhixiong Chi Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit d2efd1f20e5df7ab65497529c9fdb127de92eda4) Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

glibc: use oe_multilib_header on bits/floatn.h

2018-06-15T16:56:57+00:00

When building SDK via populate_sdk for qemuarm64 with multilib enabled, we would have conflict about bits/floatn.h at populate_sdk time. file /usr/include/bits/floatn.h conflicts between attempted ins talls of libc6-dev-2.27-r0.aarch64 and lib32-libc6-dev-2.27-r0.armv7vehf_vfp Apply oe_multilib_header on this header file to fix the problem. (From OE-Core rev: 650c59c8b6796cf4797ca1860be85f6ccf50bcd2) (From OE-Core rev: 4aabbd41e9c414d4ac765d1d343ca5d62408eaea) Signed-off-by: Chen Qi Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

glibc: Set libc_cv_ssp_all to no as well

2018-04-18T17:57:06+00:00

This is not a problem right now but if we were to use -fstack-protector-all this can cause build errors (From OE-Core rev: 271831133358b3231808e8fe7aa2817e41d98e2f) Signed-off-by: Khem Raj Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead

2018-04-07T21:34:45+00:00

Fedora28[1] has decided to go ahead and use libxcrypt to replace libcrypt from glibc despite the change not having merged into glibc upstream yet. This breaks the use of uninative in OE on fedora28 since binaries there are now using new symbols only found in libxcrypt. libxcrypt is meant to be backwards compatible with libcrypt but not the reverse. Since this will impact OE in the next release cycle, this changes nativesdk only to use this new model and adds libxcrypt to work in that case. This allows us to build a uninative which is compatible with fedora28 and previous other OSes. In order to work, recipes will now need to depend on virtual/crypt where they use libcrypt since its now a separate library and we can't depend on it from glibc to preseve backwards compatibility since glibc needs to build first. For now, only the problematic nativesdk recipes have been fixed up. For target use, the default provider remains glibc for now. Assuming this change is merged into upstream glibc, we will need to roll this change out for the target but we will do this in the next release cycle when we can better deal with the resulting bugs. [1] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Original patch from Charles-Antoine Couret , tweaked by RP to add virtual provides, SkipRecipe for libxcrypt and other minor tweaks. (From OE-Core rev: c1573cb7faeb296fe7077a60d02443d5ed5bded0) Signed-off-by: Charles-Antoine Couret Signed-off-by: Richard Purdie

libc6-dbg: improve reproducibility

2018-03-31T08:48:43+00:00

Prevent bison from generating #line comments containing build host paths references. [YOCTO #12625] (From OE-Core rev: 85af760bb7370d001df0ab5915bc9ee7e6c03dfd) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie

glibc-package: fix locale cleanup logic

2018-03-29T23:31:18+00:00

If ${libdir} is a subdirectory of ${prefix}/lib, e.g. /usr/lib/aarch64-linux, the cleanup logic will delete libc.so. This bit of code was added in 2012 (git show b744f4cc) to remove /usr/lib/locale, this commit makes it remove that directory recursively and afterwards remove /usr/lib, erroring out if it's non-empty. Tested with a plain (/usr/lib), a 64-bit (/usr/lib64) and a multiarch (/usr/lib/aarch64-linux) build. I strongly suspect this whole bit of cleanup isn't needed anymore, but my testing is too limited to be certain. (From OE-Core rev: d8f4c7794f15f7071ee8e621d7964cb4b4134630) Signed-off-by: Koen Kooi Signed-off-by: Ross Burton Signed-off-by: Richard Purdie